Regarding Xorg
Hello all, I am working on imx53 sabre board. my interest is to run Xorg on the board not Xfbdev. So I made necessary changes to ltib and build the source. but when I am running on the board I am unable to run Xorg. I am ending with following errors (EE) Failed to load module glx (module does not exist, 0) (EE) Failed to load module dri (module does not exist, 0) Could you Please help me regarding these Issue PFA for Xorg.conf , Xorg.0.log FYI I could not find libglx.so libdri.so in /usr/lib/xorg/modules/extensions location lib in usr/lib/xorg/modules/ libfb.so libshadowfb.so libvbe.solibwfb.so libxf8_16bpp.so libexa.so libint10.so libshadow.so libvgahw.so libxaa.so In usr/lib/xorg/modules/extension I have only these two libdbe.so libextmod.so In usr/lib/xorg/modules/input I have these kbd_drv.so mouse_drv.so In usr/lib/xorg/modules/drivers I have imx_drv.so In usr/lib/xorg/modules/linux I have libfbdevhw.so In usr/lib/xorg/modules/multimedia I have bt829_drv.so fi1236_drv.so msp3430_drv.so tda8425_drv.so tda9850_drv.so tda9885_drv.so uda1380_drv.so these dynamic libs Please help me How can I run Xorg Thanks Regards, Vijay Kumar Pulluri __ DISCLAIMER The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or directly to netsupp...@cmcltd.com or telephone and immediately and permanently delete the message and any attachments. Thank you. __ This email has been scrubbed for your protection by SecureMX. For more information visit http://securemx.in _ Section InputDevice Identifier Generic Keyboard Driver kbd Option XkbRules xorg Option XkbModel pc105 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer EndSection Section Device Identifier i.MX Accelerated Framebuffer Device Driver imx Option fbdev /dev/fb0 # This option only recognized when mxc_epdc_fb frame buffer driver in # use. Values are RGB565 (default, 16-bit RGB), Y8 (8-bit gray), # and Y8INV (8-bit gray inverted). Option FormatEPDCY8INV EndSection Section Monitor Identifier Configured Monitor EndSection Section Screen Identifier Default Screen Monitor Configured Monitor Device i.MX Accelerated Framebuffer Device EndSection Section ServerLayout Identifier Default Layout Screen Default Screen EndSection _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/freescale:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 X.Org X Server 1.6.1 Release Date: 2009-4-14 X Protocol Version 11, Revision 0 Build Operating System: Linux 3.0.0-17-generic-pae i686 Current Operating System: Linux freescale 2.6.35.3-998-ga1cd8a7 #6 PREEMPT Thu Apr 26 20:24:03 IST 2012 armv7l Build Date: 28 March 2012 10:32:02PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /usr/var/log/Xorg.0.log, Time: Thu Jan 1 00:02:14 1970 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor Configured Monitor (**) | |--Device i.MX Accelerated Framebuffer Device (==) Not automatically adding devices (==) Not automatically enabling devices (==) FontPath set to: built-ins (==) ModulePath set to /usr/lib/xorg/modules (==) |--Input Device Configured Mouse (==) |--Input Device Generic Keyboard (==) The core pointer device wasn't specified explicitly in the layout. Using the first core pointer device. (==) The core keyboard device wasn't specified explicitly in the layout. Using the first keyboard device. (II) Loader magic: 0xab0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on linux (--) using VT
xorg performance in general / eclipse specific question
Hi I am running an Eclipse based IDE on Ubuntu 10.04 LTS, which runs on a VMWare virtual machine on a remote server. I access the IDE on my Win 7 laptop using VcXsrv, which is an X server for Windows based on the Xorg sources. I have two questions related to this configuration. 1) Firstly, in general, the IDE is quite sluggish in this configuration. Is there anything I can do on the remote server or the local laptop to improve performance? (for example, I have heard of xorg acceleration, but I don't know what it is). 2) Secondly, I have a very specific question about the IDE behaviour. Given that this problem only manifests in a X server configuration. I thought it appropriate to ask the question here. When running the IDE, if I right click in an editor window to access a right-click menu option, the expected menu pops up but, after I select a menu item, the editor enters 'text select' mode and highlights a block of text, which is only terminated if I right-click again. I think this simply means that the IDE is getting confused about right clicks. Any ideas how to fix this please? Best regards David ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Randr window resize
On Fri, 2012-05-18 at 09:19 +0200, Eirik Byrkjeflot Anonsen wrote: Adam Jackson a...@redhat.com writes: On 5/17/12 1:33 PM, g4hx wrote: To my knowledge, this is not possible with Xorg at the moment. Correct me if I am wrong, but I think that this is a problem with the X server and not the GUI toolkits like Qt or Gtk+. You are wrong. RANDR sends events for this kind of change. If the toolkit isn't picking them up that's a toolkit bug, although I would have thought they already do. I would have expected that to be primarily the window manager's job. Sure, why not. My point was mostly that the events do happen, so wherever the bug is it's not in the server. - ajax signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: convert some more users to the screen conversion functions.
On Fri, May 18, 2012 at 12:09 AM, Keith Packard kei...@keithp.com wrote: Dave Airlie airl...@gmail.com writes: These are just some more simple patches to move to using the Screen-Scrn and Scrn-Screen conversion functions in various parts of the server. I'm wondering if you've tested these to see if the server builds without publishing the two global arrays any more. Well these + all the ABI changes + some other misc bits, I could remove xf86Screens from being exported, screenInfo is required for protocol extensions, but we can probably work on wrapping it a bit, With dynamic GPU screens, drivers doing protocol extensions will need to provide an impedance layer for that anyways. 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: lack of reviewers
Am 18.05.2012 01:14, schrieb Peter Hutterer: On Thu, May 17, 2012 at 10:39:55AM +0200, Ernst Sjöstrand wrote: Hi, (sorry for jumping in from the outside and breaking the thread!) I read about this problem and wanted to offer a suggestion! What if you set up a Gerrit server for git.freedesktop.org? That's the tool the Android OpenSource project uses among other things: https://android-review.googlesource.com/ Perhaps if it was easier to contribute to reviewing code, more people would do it more often? It's also a very nice tool I have to say, I use it every day at work. It's easy to integrate with automatic testing of patchsets before they're submitted to the repository for example. tbh I doubt what we have is a tool problem. Patches are sent to the list and can be reviewed quite easily there (for subscribers, anyway). The issue we have is manpower and, more importantly, manpower of people with enough knowledge to judge whether a patchset has side-effects beyond the obvious. in the end, such patches tend fall on the shoulders of a few and adding another tool that they have to check will increase, not decrease, the workload for those. Maybe i can be useful, since i am not a core developer but i review patches from time to time on the code only. For me the biggest problem is that i can not get the whole picture easly. When i do the same with linux patches i can go to LXR and get an idea what is going on. For *me* it would be helpful to have such a beast for X11. Getting more people into reviewing is a hard business because the motivation can be very different. just my 2 cents, re, wh ___ 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: lack of reviewers
On 18 May 2012 01:15, Peter Hutterer peter.hutte...@who-t.net wrote: On Thu, May 17, 2012 at 01:15:25PM +0200, Michal Suchanek wrote: On 17 May 2012 10:56, Olivier Galibert galib...@pobox.com wrote: On Thu, May 17, 2012 at 10:39:55AM +0200, Ernst Sjöstrand wrote: What if you set up a Gerrit server for git.freedesktop.org? When you have a social problem and try to handle it with technology, you end up with two problems. There has been no specific grumblings against the review methodology. It could, however, solve the problem with patchwork not noting which patches are applied. shouldn't that be fixed in patchwork instead of introducing another tool? It depends. Sometimes replacing the broken wheel is easier than fixing it. Is anybody working on fixing patchwork? Thanks Michal ___ 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: lack of reviewers
On 18 May 2012 01:14, Peter Hutterer peter.hutte...@who-t.net wrote: On Thu, May 17, 2012 at 10:39:55AM +0200, Ernst Sjöstrand wrote: Hi, (sorry for jumping in from the outside and breaking the thread!) I read about this problem and wanted to offer a suggestion! What if you set up a Gerrit server for git.freedesktop.org? That's the tool the Android OpenSource project uses among other things: https://android-review.googlesource.com/ Perhaps if it was easier to contribute to reviewing code, more people would do it more often? It's also a very nice tool I have to say, I use it every day at work. It's easy to integrate with automatic testing of patchsets before they're submitted to the repository for example. tbh I doubt what we have is a tool problem. Patches are sent to the list and can be reviewed quite easily there (for subscribers, anyway). The issue we have is manpower and, more importantly, manpower of people with enough knowledge to judge whether a patchset has side-effects beyond the obvious. in the end, such patches tend fall on the shoulders of a few and adding another tool that they have to check will increase, not decrease, the workload for those. tbh using a mailing list for that looks very impractical. - patches get missed completely - there is no track of what is related to what (as in the part of the same patchset or new revision of the same patchset) - you get a lots of list noise due to patches being sent one by one Thanks Michal ___ 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: lack of reviewers
On 18/05/12 19:26 , Michal Suchanek wrote: On 18 May 2012 01:14, Peter Huttererpeter.hutte...@who-t.net wrote: On Thu, May 17, 2012 at 10:39:55AM +0200, Ernst Sjöstrand wrote: Hi, (sorry for jumping in from the outside and breaking the thread!) I read about this problem and wanted to offer a suggestion! What if you set up a Gerrit server for git.freedesktop.org? That's the tool the Android OpenSource project uses among other things: https://android-review.googlesource.com/ Perhaps if it was easier to contribute to reviewing code, more people would do it more often? It's also a very nice tool I have to say, I use it every day at work. It's easy to integrate with automatic testing of patchsets before they're submitted to the repository for example. tbh I doubt what we have is a tool problem. Patches are sent to the list and can be reviewed quite easily there (for subscribers, anyway). The issue we have is manpower and, more importantly, manpower of people with enough knowledge to judge whether a patchset has side-effects beyond the obvious. in the end, such patches tend fall on the shoulders of a few and adding another tool that they have to check will increase, not decrease, the workload for those. tbh using a mailing list for that looks very impractical. - patches get missed completely true. we do encourage people to re-submit. which, aside from the obvious disadvantage, has advantages too. I found the problem with any todo list is that sooner or later it becomes so long that you either have to wipe it (by switching to a different system sometimes) or you start ignoring stuff anyway. given that one of the problems is reviewer bandwidth, I expect this to happen with any new tool. patchwork was great in the first few weeks, now it's a kitchensink great for getting URLs and not much else. requiring people to ping when patches get missed at least notifies us which patches have people behind them that care. a feature that gets submitted once, forgotten and no-one pings for it may not have been that important to begin with. - there is no track of what is related to what (as in the part of the same patchset or new revision of the same patchset) patch are usually in numbered series, in threads, with new revisinos being prefixed with v2, v3, etc. requires submitter discipline but it works to some degree. - you get a lots of list noise due to patches being sent one by one I'm not sure I follow this argument, can you expand? don't get me wrong, I don't think mailing lists is the ideal approach but I haven't seen a better one. it is an old approach and many people are well set up for the workflow so any new tool will have to have meet quite a threshold there. 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
Re: lack of reviewers
On 18 May 2012 12:40, Peter Hutterer peter.hutte...@who-t.net wrote: On 18/05/12 19:26 , Michal Suchanek wrote: On 18 May 2012 01:14, Peter Huttererpeter.hutte...@who-t.net wrote: On Thu, May 17, 2012 at 10:39:55AM +0200, Ernst Sjöstrand wrote: Hi, (sorry for jumping in from the outside and breaking the thread!) I read about this problem and wanted to offer a suggestion! What if you set up a Gerrit server for git.freedesktop.org? That's the tool the Android OpenSource project uses among other things: https://android-review.googlesource.com/ Perhaps if it was easier to contribute to reviewing code, more people would do it more often? It's also a very nice tool I have to say, I use it every day at work. It's easy to integrate with automatic testing of patchsets before they're submitted to the repository for example. tbh I doubt what we have is a tool problem. Patches are sent to the list and can be reviewed quite easily there (for subscribers, anyway). The issue we have is manpower and, more importantly, manpower of people with enough knowledge to judge whether a patchset has side-effects beyond the obvious. in the end, such patches tend fall on the shoulders of a few and adding another tool that they have to check will increase, not decrease, the workload for those. tbh using a mailing list for that looks very impractical. - patches get missed completely true. we do encourage people to re-submit. which, aside from the obvious disadvantage, has advantages too. I found the problem with any todo list is that sooner or later it becomes so long that you either have to wipe it (by switching to a different system sometimes) or you start ignoring stuff anyway. given that one of the problems is reviewer bandwidth, I expect this to happen with any new tool. patchwork was great in the first few weeks, now it's a kitchensink great for getting URLs and not much else. Given that reviewer bandwidth is scarce it would be perhaps helpful to spare it by having a tool that presents all the not-yet-reviewed patches in one place rather than reviewers fishing for them in the mailing list or in the patchwork. requiring people to ping when patches get missed at least notifies us which patches have people behind them that care. a feature that gets submitted once, forgotten and no-one pings for it may not have been that important to begin with. When you get the 5th patch for the same regression submitted the third time it starts to look like shouting your patches off a cliff in the dead of the night. - there is no track of what is related to what (as in the part of the same patchset or new revision of the same patchset) patch are usually in numbered series, in threads, with new revisinos being prefixed with v2, v3, etc. requires submitter discipline but it works to some degree. And as some of the patches get replies they get out of order and completely out of context. - you get a lots of list noise due to patches being sent one by one I'm not sure I follow this argument, can you expand? Like a series of 10+ patches for some part of the X server I do not understand landing on the list several times. I guess some people are fond of replying to the patches and quoting them in their email client and I can see that as nice feature but it's paid for by tons of list traffic. Necessarily large part of that is meaningless to most. The alternative is, of course, a link to git branch or something like that. Thanks Michal ___ 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: lack of reviewers
On Fri, May 18, 2012 at 1:17 PM, Michal Suchanek hramr...@gmail.com wrote: On 18 May 2012 12:40, Peter Hutterer peter.hutte...@who-t.net wrote: On 18/05/12 19:26 , Michal Suchanek wrote: On 18 May 2012 01:14, Peter Huttererpeter.hutte...@who-t.net wrote: On Thu, May 17, 2012 at 10:39:55AM +0200, Ernst Sjöstrand wrote: Hi, (sorry for jumping in from the outside and breaking the thread!) I read about this problem and wanted to offer a suggestion! What if you set up a Gerrit server for git.freedesktop.org? That's the tool the Android OpenSource project uses among other things: https://android-review.googlesource.com/ Perhaps if it was easier to contribute to reviewing code, more people would do it more often? It's also a very nice tool I have to say, I use it every day at work. It's easy to integrate with automatic testing of patchsets before they're submitted to the repository for example. tbh I doubt what we have is a tool problem. Patches are sent to the list and can be reviewed quite easily there (for subscribers, anyway). The issue we have is manpower and, more importantly, manpower of people with enough knowledge to judge whether a patchset has side-effects beyond the obvious. in the end, such patches tend fall on the shoulders of a few and adding another tool that they have to check will increase, not decrease, the workload for those. tbh using a mailing list for that looks very impractical. - patches get missed completely true. we do encourage people to re-submit. which, aside from the obvious disadvantage, has advantages too. I found the problem with any todo list is that sooner or later it becomes so long that you either have to wipe it (by switching to a different system sometimes) or you start ignoring stuff anyway. given that one of the problems is reviewer bandwidth, I expect this to happen with any new tool. patchwork was great in the first few weeks, now it's a kitchensink great for getting URLs and not much else. Given that reviewer bandwidth is scarce it would be perhaps helpful to spare it by having a tool that presents all the not-yet-reviewed patches in one place rather than reviewers fishing for them in the mailing list or in the patchwork. requiring people to ping when patches get missed at least notifies us which patches have people behind them that care. a feature that gets submitted once, forgotten and no-one pings for it may not have been that important to begin with. When you get the 5th patch for the same regression submitted the third time it starts to look like shouting your patches off a cliff in the dead of the night. - there is no track of what is related to what (as in the part of the same patchset or new revision of the same patchset) patch are usually in numbered series, in threads, with new revisinos being prefixed with v2, v3, etc. requires submitter discipline but it works to some degree. And as some of the patches get replies they get out of order and completely out of context. - you get a lots of list noise due to patches being sent one by one I'm not sure I follow this argument, can you expand? Like a series of 10+ patches for some part of the X server I do not understand landing on the list several times. I guess some people are fond of replying to the patches and quoting them in their email client and I can see that as nice feature but it's paid for by tons of list traffic. Necessarily large part of that is meaningless to most. The alternative is, of course, a link to git branch or something like that. Thanks Michal ___ 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 I think that a tool that allows you to see diffs in a web interface and do point-and-click defect submission would never hurt. As long as it doesn't interfere with existing processes (too much). -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ 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: convert some more users to the screen conversion functions.
Dave Airlie airl...@gmail.com writes: On Fri, May 18, 2012 at 12:09 AM, Keith Packard kei...@keithp.com wrote: Well these + all the ABI changes + some other misc bits, I could remove xf86Screens from being exported, screenInfo is required for protocol extensions, but we can probably work on wrapping it a bit, wondering if you can pull the screens out of screenInfo at least. If we're changing the desired API/ABI, it might be good to enforce it with the linker :-) With dynamic GPU screens, drivers doing protocol extensions will need to provide an impedance layer for that anyways. yeah, that's gonna be fun. -- keith.pack...@intel.com pgpZKgrCe3OZC.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: lack of reviewers
On 18 May 2012 17:38, Maarten Maathuis madman2...@gmail.com wrote: I think that a tool that allows you to see diffs in a web interface and do point-and-click defect submission would never hurt. As long as it doesn't interfere with existing processes (too much). Of course it interferes with the existing process. If it was not used it would be of no use. Thanks Michal ___ 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: convert some more users to the screen conversion functions.
On Fri, May 18, 2012 at 4:50 PM, Keith Packard kei...@keithp.com wrote: Dave Airlie airl...@gmail.com writes: On Fri, May 18, 2012 at 12:09 AM, Keith Packard kei...@keithp.com wrote: Well these + all the ABI changes + some other misc bits, I could remove xf86Screens from being exported, screenInfo is required for protocol extensions, but we can probably work on wrapping it a bit, wondering if you can pull the screens out of screenInfo at least. If we're changing the desired API/ABI, it might be good to enforce it with the linker :-) Not really, xf86Screens yes, but screenInfo.screens will still represent protocol screens going forward, and people adding extensions in their drivers will still need access to it. 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: convert some more users to the screen conversion functions.
Dave Airlie airl...@gmail.com writes: Not really, xf86Screens yes, but screenInfo.screens will still represent protocol screens going forward, yeah, there are over 500 references to screenInfo.screens in the server source code. and people adding extensions in their drivers will still need access to it. Of coruse. -- keith.pack...@intel.com pgp37YKZEG6CC.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: randr provider object
On Thu, May 17, 2012 at 10:42 PM, Keith Packard kei...@keithp.com wrote: Adam Jackson a...@nwnk.net writes: On 5/15/12 3:04 PM, Dave Airlie wrote: My concern is how you're going to build this programmatically if you keep with a poke-one-thing model, I just envision intermediate states that don't make a ton of sense on their own but that we'd end up needing to allow. What do you imagine the sequence of requests looking like? Should we try to get the everything-at-once stuff from randr 1.4 rebased and reviewed again? One thing that stymied it the first time was that extending randr for more stuff like this looked 'hard'. I think the only way to do it and keep it extensible, it to make everything a property of an object. Then the client passes a list of object types + XIDs + property/value pairs for it, we can then add new XID and properties in the future, without having to change things. So we get something like objtype,xid,propertylist , and we can add new values to objtype for new objects like providers. (outside the scope of my project ;-) 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: lack of reviewers
On Fri, May 18, 2012 at 5:56 PM, Michal Suchanek hramr...@gmail.com wrote: On 18 May 2012 17:38, Maarten Maathuis madman2...@gmail.com wrote: I think that a tool that allows you to see diffs in a web interface and do point-and-click defect submission would never hurt. As long as it doesn't interfere with existing processes (too much). Of course it interferes with the existing process. If it was not used it would be of no use. Thanks Michal You don't have to make it required, if the system is successful people will migrate out of free will. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ 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 xorg-gtest] m4: if a source is specified, use that for the include path
On 05/15/2012 04:45 PM, Chase Douglas wrote: On 05/15/2012 04:07 PM, Peter Hutterer wrote: Don't require users to specify both source and include path. We can assume that if they have the source at a certain location, they want those headers too. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- m4/gtest.m4 | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/m4/gtest.m4 b/m4/gtest.m4 index 2de334c..6722fef 100644 --- a/m4/gtest.m4 +++ b/m4/gtest.m4 @@ -25,17 +25,17 @@ # source location respectively. AC_DEFUN([CHECK_GTEST], [ - AC_ARG_WITH([gtest-include-path], - [AS_HELP_STRING([--with-gtest-include-path], - [location of the Google test headers])], - [GTEST_CPPFLAGS=-I$withval]) - AC_ARG_WITH([gtest-source-path], [AS_HELP_STRING([--with-gtest-source-path], [location of the Google test sources, defaults to /usr/src/gtest])], - [GTEST_SOURCE=$withval], + [GTEST_SOURCE=$withval; GTEST_CPPFLAGS=-I$withval/include], [GTEST_SOURCE=/usr/src/gtest]) + AC_ARG_WITH([gtest-include-path], + [AS_HELP_STRING([--with-gtest-include-path], + [location of the Google test headers])], + [GTEST_CPPFLAGS=-I$withval]) + GTEST_CPPFLAGS=$GTEST_CPPFLAGS -I$GTEST_SOURCE AC_LANG_PUSH([C++]) Looks good to me. When I merge this I will also bump the serial number at the top. This will ensure all users pull in the updated version of the file when aclocal is run. I realized that this change is against the xorg-gtest gtest.m4 script, not against the xorg-gtest.m4 aclocal script installed by xorg-gtest. The patch applies to that script as well, so I ammended it in. I have now pushed both commits in this thread. Thanks! - Chase ___ 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 2/3] Add XInput 2.x integration test framework
On 05/15/2012 05:27 PM, Peter Hutterer wrote: On Tue, May 15, 2012 at 04:56:00PM -0700, Chase Douglas wrote: On 05/15/2012 04:26 PM, Peter Hutterer wrote: one question that remains though: my impression was that xorg-gtests would go into the xorg-gtest repo but these are for the xserver repo. What's the plan here? These tests are testing the X server itself. I believe that having the tests in the upstream project repo ensures they are more likely to be run during development. I don't really see a reason for why they should live somewhere else. fair enough, but what tests would then go into the xorg-gtest repo? None. xorg-gtest is a framework upon which tests are built. xserver, utouch-frame, utouch-grail, utouch-geis, etc. all have their own tests in their own source repos. Think of xorg-gtest like Google Test or like the Check unit testing framework. They don't have tests themselves, they are frameworks for other projects to build tests upon. -- Chase ___ 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 3/3] Add test for XIQueryPointer button mask when physical touch is active
On 05/15/2012 05:25 PM, Peter Hutterer wrote:
On Tue, May 15, 2012 at 04:58:15PM -0700, Chase Douglas wrote:
On 05/15/2012 04:36 PM, Peter Hutterer wrote:
On Tue, May 15, 2012 at 11:05:27AM -0700, Chase Douglas wrote:
[snip]
diff --git
a/test/integration/recordings/ntrig_dell_xt2/touch_1_begin.record
b/test/integration/recordings/ntrig_dell_xt2/touch_1_begin.record
new file mode 100644
index 000..28a849b
--- /dev/null
+++ b/test/integration/recordings/ntrig_dell_xt2/touch_1_begin.record
@@ -0,0 +1,11 @@
+E: 1327542640.244087 0003 2745
+E: 1327542640.244089 0003 0001 1639
+E: 1327542640.244090 0003 0035 2745
+E: 1327542640.244091 0003 0036 1639
+E: 1327542640.244092 0003 0034 0
+E: 1327542640.244093 0003 0030 468
+E: 1327542640.244094 0003 0031 306
+E: 1327542640.244095 0002 0
+E: 1327542640.244251 0001 014d 1
+E: 1327542640.244251 0001 014a 1
+E: 1327542640.244253 0
we need comment suspport in evemu so we can describe what events a file
describes
Yeah, that would be helpful.
diff --git a/test/integration/recordings/ntrig_dell_xt2/touch_1_end.record
b/test/integration/recordings/ntrig_dell_xt2/touch_1_end.record
new file mode 100644
index 000..cd6a9d9
--- /dev/null
+++ b/test/integration/recordings/ntrig_dell_xt2/touch_1_end.record
@@ -0,0 +1,3 @@
+E: 1327542642.244253 0001 014d 0
+E: 1327542642.244253 0001 014a 0
+E: 1327542642.244253 0
diff --git a/test/integration/xi2.cpp b/test/integration/xi2.cpp
index 68974a9..21305d3 100644
--- a/test/integration/xi2.cpp
+++ b/test/integration/xi2.cpp
@@ -192,3 +192,79 @@ protected:
int xi2_opcode_;
};
+
+/**
+ * XIQueryPointer for XInput 2.1 and earlier should report the first
button
+ * pressed if a touch is physically active. For XInput 2.2 and later
clients,
+ * the first button should not be reported.
+ */
+TEST_P(XInput2Test, XIQueryPointerTouchscreen)
+{
+XIEventMask mask;
+mask.deviceid = XIAllDevices;
+mask.mask_len = XIMaskLen(XI_HierarchyChanged);
+mask.mask = reinterpret_castunsigned char*(
+calloc(XIMaskLen(XI_HierarchyChanged), 1));
+XISetMask(mask.mask, XI_HierarchyChanged);
+
+ASSERT_EQ(Success,
+ XISelectEvents(Display(), DefaultRootWindow(Display()),
mask,
+ 1));
+
+mask.deviceid = XIAllMasterDevices;
+XIClearMask(mask.mask, XI_HierarchyChanged);
+XISetMask(mask.mask, XI_ButtonPress);
+
+ASSERT_EQ(Success,
+ XISelectEvents(Display(), DefaultRootWindow(Display()),
mask,
+ 1));
+
+free(mask.mask);
+
+XFlush(Display());
+
+xorg::testing::evemu::Device device(
+TEST_ROOT_DIR recordings/ntrig_dell_xt2/device.prop);
+
+ASSERT_TRUE(wait_for_device(Display(),
+N-Trig MultiTouch (Virtual Test
Device)));
+
+device.Play(TEST_ROOT_DIR
recordings/ntrig_dell_xt2/touch_1_begin.record);
having the coding style mix between wait_for_device() and device.Play()
makes
me sad. can we agree on one style for xorg-gtest related stuff?
Hmm? I don't understand how the style is different between the two.
under_line_lower_case vs. CamelCase
Right. So gtest uses the Google coding style, which is CamelCase.
xserver uses under_line_lower_case. xorg-gtest, being written on top of
gtest, is CamelCase (to be fair, it was before there was a clear,
unambiguous X.org coding style :).
I imagine if/when these helper functions move to xorg-gtest, they will
become CamelCase as well, so I'll update them to be CamelCase here too.
It's not perfect, but c'est la vie.
-- Chase
___
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/2 xorg-gtest] Add comment to Makefile-xorg-gtest.am about compiling with -w
Users of xorg-gtest will not want warnings or failed builds due to issues in gtest or xorg-gtest. Note that the internal build of the xorg-gtest example does not use the -w flag when building examples, so we will still see warnings when xorg-gtest itself is built. Signed-off-by: Chase Douglas chase.doug...@canonical.com --- src/Makefile-xorg-gtest.am |3 +++ 1 file changed, 3 insertions(+) diff --git a/src/Makefile-xorg-gtest.am b/src/Makefile-xorg-gtest.am index 185381d..20983eb 100644 --- a/src/Makefile-xorg-gtest.am +++ b/src/Makefile-xorg-gtest.am @@ -26,6 +26,9 @@ XORG_GTEST_BUILD_LIBS = \ libxorg-gtest.a \ libxorg-gtest_main.a +# Here and below we compile without warnings (-w) because the projects using +# xorg-gtest will not want to see warnings or fail to build due to warnings in +# gtest or xorg-gtest. nodist_libgtest_a_SOURCES = $(GTEST_SOURCE)/src/gtest-all.cc libgtest_a_CPPFLAGS = $(GTEST_CPPFLAGS) $(AM_CPPFLAGS) -w libgtest_a_CXXFLAGS = $(GTEST_CXXFLAGS) $(AM_CXXFLAGS) -- 1.7.9.5 ___ 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/2 xorg-gtest] Namespace xorg-gtest header filenames
Due to the default automake compilation flags including -I. -I.., it is
possible to pick up an xorg-gtest header like device.h instead of a
project header. Namespacing the headers should resolve this issue. Users
should be including xorg-gtest.h instead of individual headers, so this
should not cause compilation failures.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
include/Makefile.am |8 +-
include/xorg/gtest/environment.h | 184 --
include/xorg/gtest/evemu/device.h| 91 -
include/xorg/gtest/evemu/xorg-gtest_device.h | 91 +
include/xorg/gtest/process.h | 166 ---
include/xorg/gtest/test.h| 104 ---
include/xorg/gtest/xorg-gtest.h |8 +-
include/xorg/gtest/xorg-gtest_environment.h | 184 ++
include/xorg/gtest/xorg-gtest_process.h | 166 +++
include/xorg/gtest/xorg-gtest_test.h | 104 +++
10 files changed, 553 insertions(+), 553 deletions(-)
delete mode 100644 include/xorg/gtest/environment.h
delete mode 100644 include/xorg/gtest/evemu/device.h
create mode 100644 include/xorg/gtest/evemu/xorg-gtest_device.h
delete mode 100644 include/xorg/gtest/process.h
delete mode 100644 include/xorg/gtest/test.h
create mode 100644 include/xorg/gtest/xorg-gtest_environment.h
create mode 100644 include/xorg/gtest/xorg-gtest_process.h
create mode 100644 include/xorg/gtest/xorg-gtest_test.h
diff --git a/include/Makefile.am b/include/Makefile.am
index 0256685..6b39d0b 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -24,8 +24,8 @@
#
nobase_include_HEADERS = \
- xorg/gtest/environment.h \
- xorg/gtest/process.h \
- xorg/gtest/test.h \
- xorg/gtest/evemu/device.h \
+ xorg/gtest/xorg-gtest_environment.h \
+ xorg/gtest/xorg-gtest_process.h \
+ xorg/gtest/xorg-gtest_test.h \
+ xorg/gtest/evemu/xorg-gtest_device.h \
xorg/gtest/xorg-gtest.h
diff --git a/include/xorg/gtest/environment.h b/include/xorg/gtest/environment.h
deleted file mode 100644
index e113cd7..000
--- a/include/xorg/gtest/environment.h
+++ /dev/null
@@ -1,184 +0,0 @@
-/***
- *
- * X testing environment - Google Test environment feat. dummy x server
- *
- * Copyright (C) 2011, 2012 Canonical Ltd.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a copy
- * of this software and associated documentation files (the Software), to
deal
- * in the Software without restriction, including without limitation the rights
- * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
- * copies of the Software, and to permit persons to whom the Software is
- * furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
- * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
- * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
- * SOFTWARE.
- *
-
**/
-
-#ifndef XORG_GTEST_ENVIRONMENT_H
-#define XORG_GTEST_ENVIRONMENT_H
-
-#include memory
-#include string
-
-#include gtest/gtest.h
-
-namespace xorg {
-namespace testing {
-
-/**
- * \mainpage X.org Google %Test Framework
- *
- * Xorg-gtest makes it easy to write test cases
- * for a dummy headless X.org server. It can also run tests
- * using a running X11 server.
- *
- */
-
-/**
- * @class Environment environment.h xorg/gtest/environment.h
- *
- * Global Google %Test environment providing a dummy X server.
- *
- * Starts up a dummy X server for testing purposes.
- * Either associate the environment manually
- * with the overall testing framework like
- * @code
- * xorg::testing::Environment* environment = new xorg::testing::Environment;
- * environment-set_server(Xorg);
- * environment-set_display(133);
- * environment-set_conf_file(conf/dummy.conf);
- * environment-set_log_file(/tmp/MyDummyXorg.log);
- * testing::AddGlobalTestEnvironment(environment);
- * @endcode
- * or link to libxorg-gtest_main.
- */
-class Environment : public ::testing::Environment {
- public:
- /**
- * Constructs an object to provide a global X server dummy environment.
- */
- Environment();
-
- virtual ~Environment();
-
- /**
- * Sets the path where the
Re: [PATCH v2 1/3] Add xorg-gtest integration test framework
On 05/15/2012 05:24 PM, Peter Hutterer wrote: On Tue, May 15, 2012 at 04:51:40PM -0700, Chase Douglas wrote: On 05/15/2012 04:18 PM, Peter Hutterer wrote: On Tue, May 15, 2012 at 11:05:25AM -0700, Chase Douglas wrote: [snip] + + GTEST_CPPFLAGS=$GTEST_CPPFLAGS -I$GTEST_SOURCE + + AC_CHECK_FILES([$GTEST_SOURCE/src/gtest-all.cc] + [$GTEST_SOURCE/src/gtest_main.cc], + [have_gtest=yes], + [have_gtest=no]) + + AS_IF([test x$have_gtest_source = xyes], +[AC_SUBST(GTEST_CPPFLAGS)] +[AC_SUBST(GTEST_SOURCE)]) +]) # _CHECK_GTEST + +# CHECK_XORG_GTEST([ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND]) +# +# Checks whether the xorg-gtest source is available on the system. Allows for +# adjusting the include and source path. Sets have_xorg_gtest=yes if the source +# is present. Sets XORG_GTEST_CPPFLAGS and XORG_GTEST_SOURCE to the preprocessor +# flags and source location respectively. Sets XORG_GTEST_LIBS to all the +# libraries needed to link against a built xorg-gtest library. +# +# Both default actions are no-ops. +AC_DEFUN([CHECK_XORG_GTEST], +[ + AC_REQUIRE([_CHECK_GTEST]) + + PKG_CHECK_EXISTS([xorg-gtest], + [have_xorg_gtest=yes], + [have_xorg_gtest=no]) + + XORG_GTEST_SOURCE=`$PKG_CONFIG --variable=sourcedir --print-errors xorg-gtest` + XORG_GTEST_CPPFLAGS=`$PKG_CONFIG --variable=CPPflags --print-errors xorg-gtest` + XORG_GTEST_CPPFLAGS=$GTEST_CPPFLAGS $XORG_GTEST_CPPFLAGS + XORG_GTEST_CPPFLAGS=$XORG_GTEST_CPPFLAGS -I$XORG_GTEST_SOURCE + + PKG_CHECK_MODULES(X11, [x11], [have_x11=yes], [have_x11=no]) + + # Check if we should include support for utouch-evemu + AC_ARG_WITH([evemu], + [AS_HELP_STRING([--with-evemu], + [support Linux input device recording playback does anyone actually use the term Linux input device recording playback instead of just calling it evemu? I can see a BSD user not realizing that it's Linux only. This is a file copied from the xorg-gtest distribution (via aclocal), so if you want to change it send a patch there. But I don't see why a more verbose configure help string is a problem :). mostly because I'd have no idea what Linux input device recording playback is, whereas the term evemu is slowly becoming popular given that I stick it into most bugreports these days. The option is called --with-evemu, so I hope that's clear enough. [snip] diff --git a/test/integration/Makefile-xorg-gtest.am b/test/integration/Makefile-xorg-gtest.am new file mode 100644 index 000..185381d --- /dev/null +++ b/test/integration/Makefile-xorg-gtest.am @@ -0,0 +1,61 @@ +# Copyright (C) 2012 Canonical, Ltd. +# +# Permission is hereby granted, free of charge, to any person obtaining a copy +# of this software and associated documentation files (the Software), to deal +# in the Software without restriction, including without limitation the rights +# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +# copies of the Software, and to permit persons to whom the Software is +# furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +# SOFTWARE. +# + +XORG_GTEST_BUILD_LIBS = \ + libgtest.a \ + libgtest_main.a \ + libxorg-gtest.a \ + libxorg-gtest_main.a + +nodist_libgtest_a_SOURCES = $(GTEST_SOURCE)/src/gtest-all.cc +libgtest_a_CPPFLAGS = $(GTEST_CPPFLAGS) $(AM_CPPFLAGS) -w +libgtest_a_CXXFLAGS = $(GTEST_CXXFLAGS) $(AM_CXXFLAGS) + +nodist_libgtest_main_a_SOURCES = $(GTEST_SOURCE)/src/gtest_main.cc +libgtest_main_a_CPPFLAGS = $(GTEST_CPPFLAGS) $(AM_CPPFLAGS) -w +libgtest_main_a_CXXFLAGS = $(GTEST_CXXFLAGS) $(AM_CXXFLAGS) + +nodist_libxorg_gtest_a_SOURCES = $(XORG_GTEST_SOURCE)/src/xorg-gtest-all.cpp +libxorg_gtest_a_CPPFLAGS = \ + $(XORG_GTEST_CPPFLAGS) \ + $(GTEST_CPPFLAGS) \ + $(AM_CPPFLAGS) \ + -w -w? really? Note that this is also another xorg-gtest file, so any changes would need to be patched there :). The reason for the -w here is that we don't want to cause warnings (and errors when built with -Werror) due to issues in xorg-gtest and gtest themselves. This flag is only used for building those sources. It isn't used for building any tests in the project
[PATCH v3 1/3] Add xorg-gtest integration test framework
Signed-off-by: Chase Douglas chase.doug...@canonical.com --- Changes since v2: * Refreshed xorg-gtest.m4 and Makefile-xorg-gtest.am for xorg-gtest changes configure.ac| 21 +- m4/xorg-gtest.m4| 110 +++ test/integration/Makefile-xorg-gtest.am | 64 ++ test/integration/Makefile.am|4 ++ 4 files changed, 198 insertions(+), 1 deletion(-) create mode 100644 m4/xorg-gtest.m4 create mode 100644 test/integration/Makefile-xorg-gtest.am create mode 100644 test/integration/Makefile.am diff --git a/configure.ac b/configure.ac index 97ceab1..ba10b2e 100644 --- a/configure.ac +++ b/configure.ac @@ -35,7 +35,7 @@ AM_MAINTAINER_MODE # Require xorg-macros minimum of 1.14 for XORG_COMPILER_BRAND in XORG_DEFAULT_OPTIONS m4_ifndef([XORG_MACROS_VERSION], [m4_fatal([must install xorg-macros 1.14 or later before running autoconf/autogen])]) -XORG_MACROS_VERSION(1.14) +XORG_MACROS_VERSION(1.17) XORG_DEFAULT_OPTIONS XORG_WITH_DOXYGEN(1.6.1) XORG_CHECK_SGML_DOCTOOLS(1.8) @@ -45,6 +45,7 @@ XORG_WITH_XMLTO(0.0.20) XORG_WITH_FOP XORG_WITH_XSLTPROC XORG_ENABLE_UNIT_TESTS +XORG_ENABLE_INTEGRATION_TESTS XORG_LD_WRAP([optional]) m4_ifndef([XORG_FONT_MACROS_VERSION], [m4_fatal([must install fontutil 1.1 or later before running autoconf/autogen])]) @@ -2143,6 +2144,23 @@ AM_CONDITIONAL(XEPHYR, [test x$KDRIVE = xyes test x$XEPHYR = xyes]) AM_CONDITIONAL(BUILD_KDRIVEFBDEVLIB, [test x$KDRIVE = xyes test x$KDRIVEFBDEVLIB = xyes]) AM_CONDITIONAL(XFAKESERVER, [test x$KDRIVE = xyes test x$XFAKE = xyes]) +dnl --- +dnl Tests section. +dnl --- + +if [test x$XORG = xyes test x$enable_integration_tests != xno]; then +AC_PROG_CXX +CHECK_XORG_GTEST +AM_CONDITIONAL(ENABLE_XORG_GTEST_TESTS, [test x$have_xorg_gtest = xyes]) +if [test x$have_xorg_gtest = xyes]; then +AC_MSG_NOTICE([xorg-gtest is available, tests will be built]) +elif [test x$enable_integration_tests = xyes]; then +AC_MSG_ERROR([xorg-gtest is not available]) +else +AC_MSG_NOTICE([xorg-gtest is not available, tests will not be built]) +fi +fi + dnl and the rest of these are generic, so they're in config.h dnl dnl though, thanks to the passing of some significant amount of time, the @@ -2275,6 +2293,7 @@ hw/kdrive/linux/Makefile hw/kdrive/src/Makefile test/Makefile test/xi2/Makefile +test/integration/Makefile xserver.ent xorg-server.pc ]) diff --git a/m4/xorg-gtest.m4 b/m4/xorg-gtest.m4 new file mode 100644 index 000..062842c --- /dev/null +++ b/m4/xorg-gtest.m4 @@ -0,0 +1,110 @@ +# serial 2 + +# Copyright (C) 2012 Canonical, Ltd. +# +# Permission is hereby granted, free of charge, to any person obtaining a copy +# of this software and associated documentation files (the Software), to deal +# in the Software without restriction, including without limitation the rights +# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +# copies of the Software, and to permit persons to whom the Software is +# furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +# SOFTWARE. + +# Checks whether the gtest source is available on the system. Allows for +# adjusting the include and source path. Sets have_gtest=yes if the source is +# present. Sets GTEST_CPPFLAGS and GTEST_SOURCE to the preprocessor flags and +# source location respectively. +AC_DEFUN([_CHECK_GTEST], +[ + AC_ARG_WITH([gtest-source-path], + [AS_HELP_STRING([--with-gtest-source-path], + [location of the Google test sources, defaults to /usr/src/gtest])], + [GTEST_SOURCE=$withval; GTEST_CPPFLAGS=-I$withval/include], + [GTEST_SOURCE=/usr/src/gtest]) + + AC_ARG_WITH([gtest-include-path], + [AS_HELP_STRING([--with-gtest-include-path], + [location of the Google test headers])], + [GTEST_CPPFLAGS=-I$withval]) + + GTEST_CPPFLAGS=$GTEST_CPPFLAGS -I$GTEST_SOURCE + + AC_CHECK_FILES([$GTEST_SOURCE/src/gtest-all.cc] + [$GTEST_SOURCE/src/gtest_main.cc], + [have_gtest=yes], +
[PATCH v3 2/3] Add XInput 2.x integration test framework
Signed-off-by: Chase Douglas chase.doug...@canonical.com
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
---
Changes since v2:
* Tests now build during make all
* Doxygen param statements fixed to be @param
* Switched WaitFor* functions to CamelCase to match xorg-gtest
configure.ac | 14 +++
test/integration/.gitignore |1 +
test/integration/Makefile.am | 26 +-
test/integration/xi2.cpp | 194 ++
4 files changed, 234 insertions(+), 1 deletion(-)
create mode 100644 test/integration/.gitignore
create mode 100644 test/integration/xi2.cpp
diff --git a/configure.ac b/configure.ac
index ba10b2e..0c511b8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2161,6 +2161,20 @@ if [test x$XORG = xyes test
x$enable_integration_tests != xno]; then
fi
fi
+PKG_CHECK_MODULES(TEST_X11, x11, have_test_x11=yes, have_test_x11=no)
+PKG_CHECK_MODULES(TEST_XINPUT, [xi = 1.6], have_test_xinput=yes,
have_test_xinput=no)
+
+if [test x$have_test_x11 != xyes]; then
+AC_MSG_NOTICE([libX11 not available, skipping input tests])
+elif [test x$have_test_xinput != xyes]; then
+AC_MSG_NOTICE([libXi 1.6 not available, skipping input tests])
+elif [test x$have_xorg_gtest_evemu != xyes]; then
+AC_MSG_NOTICE([uTouch-Evemu not available, skipping input tests])
+else
+enable_input_tests=yes
+fi
+AM_CONDITIONAL(ENABLE_XORG_GTEST_INPUT_TESTS, [test x$enable_input_tests =
xyes])
+
dnl and the rest of these are generic, so they're in config.h
dnl
dnl though, thanks to the passing of some significant amount of time, the
diff --git a/test/integration/.gitignore b/test/integration/.gitignore
new file mode 100644
index 000..ab86ebf
--- /dev/null
+++ b/test/integration/.gitignore
@@ -0,0 +1 @@
+gtest-tests
diff --git a/test/integration/Makefile.am b/test/integration/Makefile.am
index e70d642..ff9789e 100644
--- a/test/integration/Makefile.am
+++ b/test/integration/Makefile.am
@@ -1,4 +1,28 @@
+TESTS =
+
if ENABLE_XORG_GTEST_TESTS
include $(top_srcdir)/test/integration/Makefile-xorg-gtest.am
-check_LIBRARIES = $(XORG_GTEST_BUILD_LIBS)
+noinst_LIBRARIES = $(XORG_GTEST_BUILD_LIBS)
+
+if ENABLE_XORG_GTEST_INPUT_TESTS
+TESTS += gtest-tests
endif
+endif
+
+noinst_PROGRAMS = $(TESTS)
+
+AM_CPPFLAGS = \
+ -DDEFAULT_XORG_SERVER=\$(abs_top_builddir)/hw/xfree86/Xorg\ \
+ -DTEST_ROOT_DIR=\$(abs_top_srcdir)/test/integration/\ \
+ $(GTEST_CPPFLAGS) \
+ $(XORG_GTEST_CPPFLAGS)
+
+AM_CXXFLAGS = $(GTEST_CXXFLAGS) $(XORG_GTEST_CXXFLAGS)
+
+gtest_tests_SOURCES = xi2.cpp
+gtest_tests_LDADD = \
+ $(TEST_XINPUT_LIBS) \
+ $(TEST_X11_LIBS) \
+ $(XORG_GTEST_LIBS) \
+ $(EVEMU_LIBS) \
+ $(XORG_GTEST_MAIN_LIBS)
diff --git a/test/integration/xi2.cpp b/test/integration/xi2.cpp
new file mode 100644
index 000..d3c3a30
--- /dev/null
+++ b/test/integration/xi2.cpp
@@ -0,0 +1,194 @@
+#include stdexcept
+
+#include xorg/gtest/xorg-gtest.h
+
+#include X11/extensions/XInput2.h
+
+namespace {
+
+/**
+ * Wait for an event on the X connection.
+ *
+ * @param [in] display The X display connection
+ * @param [in] timeout The timeout in milliseconds
+ *
+ * @return Whether an event is available
+ */
+bool WaitForEvent(::Display *display, time_t timeout = 1000)
+{
+fd_set fds;
+FD_ZERO(fds);
+
+int display_fd = ConnectionNumber(display);
+
+XSync(display, False);
+
+if (XPending(display))
+return true;
+else {
+FD_SET(display_fd, fds);
+
+struct timeval timeval = {
+static_casttime_t(timeout / 1000),
+static_casttime_t(timeout % 1000),
+};
+
+int ret;
+if (timeout)
+ret = select(display_fd + 1, fds, NULL, NULL, timeval);
+else
+ret = select(display_fd + 1, fds, NULL, NULL, NULL);
+
+if (ret 0)
+throw std::runtime_error(Failed to select on X fd);
+
+if (ret == 0)
+return false;
+
+return XPending(display);
+}
+}
+
+/**
+ * Wait for an event of a specific type on the X connection.
+ *
+ * All events preceding the matching event are discarded. If no event was found
+ * before the timeout expires, all events in the queue will have been
discarded.
+ *
+ * @param [in] display The X display connection
+ * @param [in] type The X core protocol event type
+ * @param [in] extension The X extension opcode of a generic event, or -1 for
+ * any generic event
+ * @param [in] evtypeThe X extension event type of a generic event, or -1
+ * for any event of the given extension
+ * @param [in] timeout The timeout in milliseconds
+ *
+ * @return Whether an event is available
+ */
+bool WaitForEventOfType(::Display *display, int type, int extension, int
evtype,
+time_t timeout = 1000)
+{
+while (WaitForEvent(display)) {
+XEvent event;
+if (!XPeekEvent(display, event))
[PATCH v3 3/3] Add test for XIQueryPointer button mask when physical touch is active
Signed-off-by: Chase Douglas chase.doug...@canonical.com
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
---
Changes since v2:
* Refreshed due to function name changes in patch 2/3
.../recordings/ntrig_dell_xt2/device.prop | 32 +
.../recordings/ntrig_dell_xt2/touch_1_begin.record | 11 +++
.../recordings/ntrig_dell_xt2/touch_1_end.record |3 +
test/integration/xi2.cpp | 76
4 files changed, 122 insertions(+)
create mode 100644 test/integration/recordings/ntrig_dell_xt2/device.prop
create mode 100644
test/integration/recordings/ntrig_dell_xt2/touch_1_begin.record
create mode 100644
test/integration/recordings/ntrig_dell_xt2/touch_1_end.record
diff --git a/test/integration/recordings/ntrig_dell_xt2/device.prop
b/test/integration/recordings/ntrig_dell_xt2/device.prop
new file mode 100644
index 000..2738c04
--- /dev/null
+++ b/test/integration/recordings/ntrig_dell_xt2/device.prop
@@ -0,0 +1,32 @@
+N: N-Trig MultiTouch (Virtual Test Device)
+I: 0003 1b96 0001 0110
+P: 00 00 00 00 00 00 00 00
+B: 00 0b 00 00 00 00 00 00 00
+B: 01 00 00 00 00 00 00 00 00
+B: 01 00 00 00 00 00 00 00 00
+B: 01 00 00 00 00 00 00 00 00
+B: 01 00 00 00 00 00 00 00 00
+B: 01 00 00 00 00 00 00 00 00
+B: 01 00 04 00 00 00 00 00 00
+B: 01 00 00 00 00 00 00 00 00
+B: 01 00 00 00 00 00 00 00 00
+B: 01 00 00 00 00 00 00 00 00
+B: 01 00 00 00 00 00 00 00 00
+B: 01 00 00 00 00 00 00 00 00
+B: 01 00 00 00 00 00 00 00 00
+B: 02 00 00 00 00 00 00 00 00
+B: 03 03 00 00 00 00 01 73 00
+B: 04 00 00 00 00 00 00 00 00
+B: 05 00 00 00 00 00 00 00 00
+B: 11 00 00 00 00 00 00 00 00
+B: 12 00 00 00 00 00 00 00 00
+B: 15 00 00 00 00 00 00 00 00
+B: 15 00 00 00 00 00 00 00 00
+A: 00 0 9600 75 0
+A: 01 0 7200 78 0
+A: 28 0 255 0 0
+A: 30 0 9600 200 0
+A: 31 0 7200 150 0
+A: 34 0 1 0 0
+A: 35 0 9600 75 0
+A: 36 0 7200 78 0
diff --git a/test/integration/recordings/ntrig_dell_xt2/touch_1_begin.record
b/test/integration/recordings/ntrig_dell_xt2/touch_1_begin.record
new file mode 100644
index 000..28a849b
--- /dev/null
+++ b/test/integration/recordings/ntrig_dell_xt2/touch_1_begin.record
@@ -0,0 +1,11 @@
+E: 1327542640.244087 0003 2745
+E: 1327542640.244089 0003 0001 1639
+E: 1327542640.244090 0003 0035 2745
+E: 1327542640.244091 0003 0036 1639
+E: 1327542640.244092 0003 0034 0
+E: 1327542640.244093 0003 0030 468
+E: 1327542640.244094 0003 0031 306
+E: 1327542640.244095 0002 0
+E: 1327542640.244251 0001 014d 1
+E: 1327542640.244251 0001 014a 1
+E: 1327542640.244253 0
diff --git a/test/integration/recordings/ntrig_dell_xt2/touch_1_end.record
b/test/integration/recordings/ntrig_dell_xt2/touch_1_end.record
new file mode 100644
index 000..cd6a9d9
--- /dev/null
+++ b/test/integration/recordings/ntrig_dell_xt2/touch_1_end.record
@@ -0,0 +1,3 @@
+E: 1327542642.244253 0001 014d 0
+E: 1327542642.244253 0001 014a 0
+E: 1327542642.244253 0
diff --git a/test/integration/xi2.cpp b/test/integration/xi2.cpp
index d3c3a30..e6cd312 100644
--- a/test/integration/xi2.cpp
+++ b/test/integration/xi2.cpp
@@ -192,3 +192,79 @@ protected:
int xi2_opcode_;
};
+
+/**
+ * XIQueryPointer for XInput 2.1 and earlier should report the first button
+ * pressed if a touch is physically active. For XInput 2.2 and later clients,
+ * the first button should not be reported.
+ */
+TEST_P(XInput2Test, XIQueryPointerTouchscreen)
+{
+XIEventMask mask;
+mask.deviceid = XIAllDevices;
+mask.mask_len = XIMaskLen(XI_HierarchyChanged);
+mask.mask = reinterpret_castunsigned char*(
+calloc(XIMaskLen(XI_HierarchyChanged), 1));
+XISetMask(mask.mask, XI_HierarchyChanged);
+
+ASSERT_EQ(Success,
+ XISelectEvents(Display(), DefaultRootWindow(Display()), mask,
+ 1));
+
+mask.deviceid = XIAllMasterDevices;
+XIClearMask(mask.mask, XI_HierarchyChanged);
+XISetMask(mask.mask, XI_ButtonPress);
+
+ASSERT_EQ(Success,
+ XISelectEvents(Display(), DefaultRootWindow(Display()), mask,
+ 1));
+
+free(mask.mask);
+
+XFlush(Display());
+
+xorg::testing::evemu::Device device(
+TEST_ROOT_DIR recordings/ntrig_dell_xt2/device.prop);
+
+ASSERT_TRUE(WaitForDevice(Display(),
+ N-Trig MultiTouch (Virtual Test Device)));
+
+device.Play(TEST_ROOT_DIR
recordings/ntrig_dell_xt2/touch_1_begin.record);
+
+ASSERT_TRUE(WaitForEventOfType(Display(), GenericEvent, xi2_opcode_,
+ XI_ButtonPress));
+
+XEvent event;
+ASSERT_EQ(Success, XNextEvent(Display(), event));
+
+XGenericEventCookie *xcookie = event.xcookie;
+ASSERT_TRUE(XGetEventData(Display(), xcookie));
+
+XIDeviceEvent *device_event =
+reinterpret_castXIDeviceEvent*(xcookie-data);
+
+Window root;
+Window child;
+double root_x;
+double root_y;
+double win_x;
+double win_y;
+
[PATCH v2 1/2] Add test for touch end on device disable
When a device is disabled, all physically active touches must end.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
---
test/integration/xi2.cpp | 71 ++
1 file changed, 71 insertions(+)
diff --git a/test/integration/xi2.cpp b/test/integration/xi2.cpp
index e6cd312..b3cb0a5 100644
--- a/test/integration/xi2.cpp
+++ b/test/integration/xi2.cpp
@@ -2,6 +2,7 @@
#include xorg/gtest/xorg-gtest.h
+#include X11/extensions/XInput.h
#include X11/extensions/XInput2.h
namespace {
@@ -267,4 +268,74 @@ TEST_P(XInput2Test, XIQueryPointerTouchscreen)
XFreeEventData(Display(), xcookie);
}
+/**
+ * When a device is disabled, any physically active touches should end.
+ */
+TEST_P(XInput2Test, DisableDeviceEndTouches)
+{
+/* This is an XInput 2.2 and later test only */
+if (GetParam() 2)
+return;
+
+XIEventMask mask;
+mask.deviceid = XIAllDevices;
+mask.mask_len = XIMaskLen(XI_TouchEnd);
+mask.mask = reinterpret_castunsigned char*(
+calloc(XIMaskLen(XI_HierarchyChanged), 1));
+XISetMask(mask.mask, XI_HierarchyChanged);
+
+ASSERT_EQ(Success,
+ XISelectEvents(Display(), DefaultRootWindow(Display()), mask,
+ 1));
+
+mask.deviceid = XIAllMasterDevices;
+XIClearMask(mask.mask, XI_HierarchyChanged);
+XISetMask(mask.mask, XI_TouchBegin);
+XISetMask(mask.mask, XI_TouchUpdate);
+XISetMask(mask.mask, XI_TouchEnd);
+
+ASSERT_EQ(Success,
+ XISelectEvents(Display(), DefaultRootWindow(Display()), mask,
+ 1));
+
+free(mask.mask);
+
+XFlush(Display());
+
+xorg::testing::evemu::Device device(
+TEST_ROOT_DIR recordings/ntrig_dell_xt2/device.prop);
+
+ASSERT_TRUE(wait_for_device(Display(),
+N-Trig MultiTouch (Virtual Test Device)));
+
+device.Play(TEST_ROOT_DIR
recordings/ntrig_dell_xt2/touch_1_begin.record);
+
+ASSERT_TRUE(wait_for_event_of_type(Display(), GenericEvent, xi2_opcode_,
+ XI_TouchBegin));
+
+XEvent event;
+ASSERT_EQ(Success, XNextEvent(Display(), event));
+
+XGenericEventCookie *xcookie = event.xcookie;
+ASSERT_TRUE(XGetEventData(Display(), xcookie));
+
+XIDeviceEvent *device_event =
+reinterpret_castXIDeviceEvent*(xcookie-data);
+
+XDevice *xdevice = XOpenDevice(Display(), device_event-sourceid);
+XFreeEventData(Display(), xcookie);
+ASSERT_TRUE(xdevice != NULL);
+
+XDeviceEnableControl enable_control;
+enable_control.enable = false;
+XDeviceControl *control = reinterpret_castXDeviceControl*(control);
+ASSERT_TRUE(XChangeDeviceControl(Display(), xdevice, DEVICE_ENABLE,
+ control));
+XCloseDevice(Display(), xdevice);
+XFlush(Display());
+
+ASSERT_TRUE(wait_for_event_of_type(Display(), GenericEvent, xi2_opcode_,
+ XI_TouchEnd));
+}
+
INSTANTIATE_TEST_CASE_P(, XInput2Test, ::testing::Range(0, 3));
--
1.7.9.5
___
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 2/2] End physically active touches when device is disabled
Otherwise:
* We can't end the touches while device is disabled
* New touches after enabling the device may erroneously be mapped to old
logical touches
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
Changes since v1:
* Block signals while ending touches
* Process all enqueued input events before processing still-active touches
* Move function to dix/touch.c and prefix with Touch
dix/devices.c |1 +
dix/touch.c | 28
include/input.h |1 +
3 files changed, 30 insertions(+)
diff --git a/dix/devices.c b/dix/devices.c
index 0c62a01..dc5f51c 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -437,6 +437,7 @@ DisableDevice(DeviceIntPtr dev, BOOL sendevent)
if (*prev != dev)
return FALSE;
+TouchEndPhysicallyActiveTouches(dev);
ReleaseButtonsAndKeys(dev);
SyncRemoveDeviceIdleTime(dev-idle_counter);
dev-idle_counter = NULL;
diff --git a/dix/touch.c b/dix/touch.c
index 401cb98..c9f72a9 100644
--- a/dix/touch.c
+++ b/dix/touch.c
@@ -1028,3 +1028,31 @@ TouchAcceptReject(ClientPtr client, DeviceIntPtr dev,
int mode,
return TouchListenerAcceptReject(dev, ti, i, mode);
}
+
+/**
+ * End physically active touches for a device.
+ */
+void
+TouchEndPhysicallyActiveTouches(DeviceIntPtr dev)
+{
+InternalEvent *eventlist = InitEventList(GetMaximumEventsNum());
+int i;
+
+OsBlockSignals();
+mieqProcessInputEvents();
+for (i = 0; i dev-last.num_touches; i++) {
+DDXTouchPointInfoPtr ddxti = dev-last.touches + i;
+
+if (ddxti-active) {
+int j;
+int nevents = GetTouchEvents(eventlist, dev, ddxti-ddx_id,
+ XI_TouchEnd, 0, NULL);
+
+for (j = 0; j nevents; j++)
+mieqProcessDeviceEvent(dev, eventlist + j, NULL);
+}
+}
+OsReleaseSignals();
+
+FreeEventList(eventlist, GetMaximumEventsNum());
+}
diff --git a/include/input.h b/include/input.h
index bcf98a6..c702929 100644
--- a/include/input.h
+++ b/include/input.h
@@ -579,6 +579,7 @@ extern int TouchListenerAcceptReject(DeviceIntPtr dev,
TouchPointInfoPtr ti,
int listener, int mode);
extern int TouchAcceptReject(ClientPtr client, DeviceIntPtr dev, int mode,
uint32_t touchid, Window grab_window, XID *error);
+extern void TouchEndPhysicallyActiveTouches(DeviceIntPtr dev);
/* misc event helpers */
extern Mask GetEventMask(DeviceIntPtr dev, xEvent *ev, InputClientsPtr
clients);
--
1.7.9.5
___
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: randr provider object
Dave Airlie airl...@gmail.com writes: I think the only way to do it and keep it extensible, it to make everything a property of an object. Not sure it has to be 'properties', but surely something where you can set a bunch of 'pending' values, and then push the 'go' button and have the whole set either succeed or fail. So we get something like objtype,xid,propertylist , and we can add new values to objtype for new objects like providers. I'd like to keep the data on the wire structured if possible; the notion of a type-less protocol just doesn't appeal. (outside the scope of my project ;-) But, alas, relevant if we want this to actually work. -- keith.pack...@intel.com pgpf5snzqBUlS.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] xserver: drop index argument to ScreenInit (ABI/API) (v2)
On 05/15/12 11:44 AM, Dave Airlie wrote: This drops the index argument, its the same as pScreen-myNum, and its the last major index abuse I can find. v2: address Alan's review - update docs, fix xwin/xnest/darwin Signed-off-by: Dave Airlie airl...@redhat.com Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] ddc: change API to take ScrnInfoPtr (v2)
On 05/15/12 11:50 AM, Dave Airlie wrote: This removes all xf86Screens usage from ddc code, it modifies the API for some functions to avoid taking indices. v2: address Alan's comments about dropping DDC2Init parameter. Signed-off-by: Dave Airlie airl...@redhat.com Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10/vbe: don't use xf86Screens. (ABI) (v2)
On 05/15/12 11:52 AM, Dave Airlie wrote: Pass the ScrnInfoPtr instead of the index in the int10 struct. This saves us using it to dereference xf86Screens. v2: address Alan's comment to fix struct alignment. Signed-off-by: Dave Airlie airl...@redhat.com Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: lack of reviewers
Hi, On 18 May 2012 20:05, Maarten Maathuis madman2...@gmail.com wrote: On Fri, May 18, 2012 at 5:56 PM, Michal Suchanek hramr...@gmail.com wrote: Of course it interferes with the existing process. If it was not used it would be of no use. You don't have to make it required, if the system is successful people will migrate out of free will. I'm not sure I have too much to add to this discussion, since I'm yet another person who's entirely qualified to do reviews but just isn't. As for the tool issues, however - patchwork exists and does that, and does indeed have a git hook that's supposed to clean up patches which have been committed. Whether or not this works or happens is irrelevant, the fact is that it could be made to do so if it doesn't already with much less typing than has been expended on this thread already. 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
