[ANNOUNCE] libXi 1.5.99.2
A rather small set of changes, the XI 2.2 additions are all in just one patch instead of a set of them. Grab this one if you want to start testing multitouch features (once the server is there). Peter Hutterer (3): Bump to 1.5.99.1 Implement support for XI 2.2 libXi 1.5.99.2 git tag: libXi-1.5.99.2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.99.2.tar.bz2 MD5: b0719f6be5eda663a0a1fbac5aa00c76 libXi-1.5.99.2.tar.bz2 SHA1: 7c1be5426297889daac91c0d669200ea3ec93582 libXi-1.5.99.2.tar.bz2 SHA256: 855e91bc7bd61b2870373bf3b081eb76bd320e2104c4ee7b5018473092d76e5c libXi-1.5.99.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.99.2.tar.gz MD5: 831824136b92c2a4147b6d02d950aa49 libXi-1.5.99.2.tar.gz SHA1: 1883ffd78db9f5e70322ed6f551e43fbaea275d9 libXi-1.5.99.2.tar.gz SHA256: 90443bd649f38828f5b71d4fd842f5b735d26c110d540f39349a8bcb858c27b2 libXi-1.5.99.2.tar.gz pgp6I2STNYvp0.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] libXi 1.5.99.2
A rather small set of changes, the XI 2.2 additions are all in just one patch instead of a set of them. Grab this one if you want to start testing multitouch features (once the server is there). Peter Hutterer (3): Bump to 1.5.99.1 Implement support for XI 2.2 libXi 1.5.99.2 git tag: libXi-1.5.99.2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.99.2.tar.bz2 MD5: b0719f6be5eda663a0a1fbac5aa00c76 libXi-1.5.99.2.tar.bz2 SHA1: 7c1be5426297889daac91c0d669200ea3ec93582 libXi-1.5.99.2.tar.bz2 SHA256: 855e91bc7bd61b2870373bf3b081eb76bd320e2104c4ee7b5018473092d76e5c libXi-1.5.99.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.99.2.tar.gz MD5: 831824136b92c2a4147b6d02d950aa49 libXi-1.5.99.2.tar.gz SHA1: 1883ffd78db9f5e70322ed6f551e43fbaea275d9 libXi-1.5.99.2.tar.gz SHA256: 90443bd649f38828f5b71d4fd842f5b735d26c110d540f39349a8bcb858c27b2 libXi-1.5.99.2.tar.gz pgpoEb7L40L1S.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xinput 1.5.4
One fix required for xinput to work when compiled against newer inputproto headers. Without this fix, xinput will check the server for whichever the current protocol version is (or higher) and fail if that version is not present. If you are updating the inputproto headers to 2.1 or a 2.2RC, you will need this update. Peter Hutterer (2): list: don't use defines for checking server version. xinput 1.5.4 git tag: xinput-1.5.4 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.4.tar.bz2 MD5: 69cd4dea77915b87c106003668378749 xinput-1.5.4.tar.bz2 SHA1: 4e77f4034aa4bc720726beb0795d77a47a71d2c8 xinput-1.5.4.tar.bz2 SHA256: a8da86f0d7c8ac0c4434e3140ae7f208fc2b35869e5adf10971eef7cb77f4360 xinput-1.5.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.4.tar.gz MD5: f6b165d11d7c46b7113aaa9ecc380d51 xinput-1.5.4.tar.gz SHA1: 82a3f64f8ec2cca2c1f22247367004727a41864f xinput-1.5.4.tar.gz SHA256: ffdee8ae80e1ad62f266f4e537a9809920fbfca670185cd9131d4896d6fd5035 xinput-1.5.4.tar.gz pgpWRpyC9IOlr.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XInput: Atmel maXTouch Digitizer touch screen
On Wed, Dec 21, 2011 at 11:52:39PM +0100, Ben Bucksch wrote: I have unsuccessfully tried the whole day to configure the Atmel maXTouch Digitizer with USB ID 03eb:211c . This is a touch screen and does appear in X.org as input device. It is working rudimentary, but bad enough to be unusable. The machine is a Samsung Series 7 Slate XE700T1A, a tablet with standard notebook hardware. I am using Ubuntu 11.10 with Ubuntu kernel 3.0.0-14-generic and xorg-server 1.10.4-1ubuntu4.2. Problems: 1. ABSOLUTE By default, it's configured in Mode RELATIVE, but it's ABSOLUTE. When I do xinput --set-mode Atmel Atmel maXTouch Digitizer ABSOLUTE it works. But I need it at the login screen already. I do not understand how to just change certain config options about an input device without changing the whole config. When I put in /etc/X11/x.org.conf.d/atmel.conf : Section InputClass Identifier Atmel touchscreen MatchProduct Atmel Atmel maXTouch Digitizer MatchIsTouchpad on Option Mode Absolute EndSection then I get a complaint in the X.org log that the Driver is missing (yes, I shouldn't get that and I don't understand why I do). If I use Driver synaptics, X.org log complains that it's not a synaptics device. If I use Driver evdev, the clicking (mouse button, tapping) doesn't at all work anymore. Either way, this should work OOTB. Can somebody please fix the driver to make it know that this device is ABSOLUTE? please attach your log, it's too hard to guess which configuration doesn't apply correctly. 2. Button not released Sometimes, it generates only button 1 pressed, but not button 1 released. as Chase said, probably broken kernel driver or device. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libXi 1.5.0
libXi 1.5.0 is an interim version of libXi that includes the smooth scrolling support that XI 2.1 brings. Note that no servers released by X.Org currently supports smooth scrolling, this feature is still limited to the 1.12 development versions. In addition to the smooth scrolling support, this release brings a number of cleanups, bugfixes (most of which were on 1.4.5) and a set of man page improvements. Alan Coopersmith (3): Move Xinput server API documentation from libXi to xserver Fix the FIXME output in man page .TH macros generated by asciidoc Make shadow man pages generated by asciidoc work with Solaris man Gaetan Nadon (13): Documentation: add Docbook external references support make: remove unneeded AM_V_GEN silent rule directive. make: use AM_V_at rather than AM_V_GEN to prefix the mv command Install target dbs alongside generated documents Install xml versions of specs even if HAVE_XMLTO is false docbook.am: global maintenance update - entities, images and olinking docbook.am: embed css styles inside the HTML HEAD element docs: remove productnumber which is not used by default docs: use the fullrelvers; entity to set X11 release information inputlib: fix copyright statements inputlib: prefix 1.0 with the word Version inputlib: restore original title X Input Device Extension Library specs: refactor and complete copyright legal text Jeremy Huddleston (1): Use AM_CPPFLAGS to use in tree headers before installed headers Matt Dew (2): Add id attributes to funcsynopsis to allow other docs to olink to them. 1 - fix the capitalization of the ID attriutes to match either the Matthieu Herrb (1): Fix XISelectEvents on 64 bits, strict alignement architectures. Peter Hutterer (34): Allocate enough memory for raw events + extra data. XIChangeHierarchy: Return Success early if no actual changes are requested. Remove a few unused assignments. man: fix typo, layout in XGetExtensionVersion.man Silence compiler warning in XListDProp.c Silence compiler warning due to differnent event conversion procs man: fix missing comma in XIGrabEnter man page Use Data, not Data32 in XIPassiveGrabDevice man: Fix wrong event names in XIGrabButton. man: Fix typo in XIChangeProperty Bump to 1.4.99 man: Fix formatting in XGetFeedbackControl Add XI2 library-internal array offsets to XIint.h Don't use the protocol defines for 2.0 versioning. Handle unknown device classes. man: fix typo in XIQueryDevice man page man: update property and grab man pages for new constants Handle unknown device classes. man: fix typo in XIQueryDevice man page man: update property and grab man pages for new constants Require inputproto 2.0.99.1 or later Support XI 2.1 internally Support XI 2.1 XIScrollClass Use a separate nclasses variable in XIQueryDevice Remove superfluous assignment of lib-classes in XIQueryDevices. Bump to 1.4.99.1 man: fix #include for XIGrabButton man: XIGrabButton returns error codes, not status codes man: passive grabs return the number of failed modifier combinations Fix duplicate sizeof in copy_classes Stop unnecessary calls to size_classes Include config.h from source files man: minor formatting fix in XIGrabButton libXi 1.5.0 git tag: libXi-1.5.0 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.0.tar.bz2 MD5: eed79448dd24b31f3fedb1750fc777b3 libXi-1.5.0.tar.bz2 SHA1: 2d5219ecd270ba985f3a6f4fa3a17c033bb05b78 libXi-1.5.0.tar.bz2 SHA256: fa4a9e4749a439c7a7911e366a898862158c802a0ff8ea0c73f98201aefb4f85 libXi-1.5.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.0.tar.gz MD5: 0a67031dfb02284ee8de297c4aad6743 libXi-1.5.0.tar.gz SHA1: c9b7b005685548d5ebe51e0e270a7c9aba5b6d0a libXi-1.5.0.tar.gz SHA256: 083a520bb9a8cbbfa2b502ddf89cf027e47f24dcce35f087ae54070181f05a5a libXi-1.5.0.tar.gz pgprOCoMel6fz.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] inputproto 2.1.99.4
The XI 2.2 (multitouch) protocol spec is now merged into master, so here's a new snapshot after the merge. Most of these commits were part of XI 2.1, the announce generator is a bit naïve. No functional changes in the input protocol since 2.1.99.3. The protocol does not require any configure flags or defines anymore. One bugfix: the dropped libXi version defines are reinstated so this version should work with older versions of libXi. Cyril Brulebois (1): specs: Fix tiny typo. Peter Hutterer (14): specs: clarify that Preferred scroll valuators are per scroll direction specs: We're up to version 2.1 now, say so specs: scroll events have no specific event type, state so. specs: smooth scrolling was added in 2.1, say so specs: typo fix specs: drop leftover from active_touches removal specs: clarify button state in touch events inputproto 2.1 Drop wrong comment for sourceid in TouchOwnershipEvents Reinstate libXi's version defines specs: remove parts of the Work in progress warning Remove --enable-unstable-protocol configure option specs: add XI 2.1 release to history section inputproto 2.1.99.4 git tag: inputproto-2.1.99.4 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.4.tar.bz2 MD5: 32f30ddfa1a69b142f3ed12ee501f5e8 inputproto-2.1.99.4.tar.bz2 SHA1: d269d2da4b4812a5dd49d5d678803489b24dd5b8 inputproto-2.1.99.4.tar.bz2 SHA256: 9446966f39596657bd7fe7bab715faf95b118bf9c5962becd67ed0a17572c5f2 inputproto-2.1.99.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.4.tar.gz MD5: 8a2c92e64cf94900ba86a91ff63d6fbc inputproto-2.1.99.4.tar.gz SHA1: 669a431a7ed9ba74e72592e225695b527faa9a85 inputproto-2.1.99.4.tar.gz SHA256: 5da1e3a09a6f0c661dfe6ca9a753ca74992bb36466f4bcfa0282e198ca438b98 inputproto-2.1.99.4.tar.gz pgp3ZxvzZpaiG.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] libXi 1.5.0
libXi 1.5.0 is an interim version of libXi that includes the smooth scrolling support that XI 2.1 brings. Note that no servers released by X.Org currently supports smooth scrolling, this feature is still limited to the 1.12 development versions. In addition to the smooth scrolling support, this release brings a number of cleanups, bugfixes (most of which were on 1.4.5) and a set of man page improvements. Alan Coopersmith (3): Move Xinput server API documentation from libXi to xserver Fix the FIXME output in man page .TH macros generated by asciidoc Make shadow man pages generated by asciidoc work with Solaris man Gaetan Nadon (13): Documentation: add Docbook external references support make: remove unneeded AM_V_GEN silent rule directive. make: use AM_V_at rather than AM_V_GEN to prefix the mv command Install target dbs alongside generated documents Install xml versions of specs even if HAVE_XMLTO is false docbook.am: global maintenance update - entities, images and olinking docbook.am: embed css styles inside the HTML HEAD element docs: remove productnumber which is not used by default docs: use the fullrelvers; entity to set X11 release information inputlib: fix copyright statements inputlib: prefix 1.0 with the word Version inputlib: restore original title X Input Device Extension Library specs: refactor and complete copyright legal text Jeremy Huddleston (1): Use AM_CPPFLAGS to use in tree headers before installed headers Matt Dew (2): Add id attributes to funcsynopsis to allow other docs to olink to them. 1 - fix the capitalization of the ID attriutes to match either the Matthieu Herrb (1): Fix XISelectEvents on 64 bits, strict alignement architectures. Peter Hutterer (34): Allocate enough memory for raw events + extra data. XIChangeHierarchy: Return Success early if no actual changes are requested. Remove a few unused assignments. man: fix typo, layout in XGetExtensionVersion.man Silence compiler warning in XListDProp.c Silence compiler warning due to differnent event conversion procs man: fix missing comma in XIGrabEnter man page Use Data, not Data32 in XIPassiveGrabDevice man: Fix wrong event names in XIGrabButton. man: Fix typo in XIChangeProperty Bump to 1.4.99 man: Fix formatting in XGetFeedbackControl Add XI2 library-internal array offsets to XIint.h Don't use the protocol defines for 2.0 versioning. Handle unknown device classes. man: fix typo in XIQueryDevice man page man: update property and grab man pages for new constants Handle unknown device classes. man: fix typo in XIQueryDevice man page man: update property and grab man pages for new constants Require inputproto 2.0.99.1 or later Support XI 2.1 internally Support XI 2.1 XIScrollClass Use a separate nclasses variable in XIQueryDevice Remove superfluous assignment of lib-classes in XIQueryDevices. Bump to 1.4.99.1 man: fix #include for XIGrabButton man: XIGrabButton returns error codes, not status codes man: passive grabs return the number of failed modifier combinations Fix duplicate sizeof in copy_classes Stop unnecessary calls to size_classes Include config.h from source files man: minor formatting fix in XIGrabButton libXi 1.5.0 git tag: libXi-1.5.0 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.0.tar.bz2 MD5: eed79448dd24b31f3fedb1750fc777b3 libXi-1.5.0.tar.bz2 SHA1: 2d5219ecd270ba985f3a6f4fa3a17c033bb05b78 libXi-1.5.0.tar.bz2 SHA256: fa4a9e4749a439c7a7911e366a898862158c802a0ff8ea0c73f98201aefb4f85 libXi-1.5.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.0.tar.gz MD5: 0a67031dfb02284ee8de297c4aad6743 libXi-1.5.0.tar.gz SHA1: c9b7b005685548d5ebe51e0e270a7c9aba5b6d0a libXi-1.5.0.tar.gz SHA256: 083a520bb9a8cbbfa2b502ddf89cf027e47f24dcce35f087ae54070181f05a5a libXi-1.5.0.tar.gz pgpiJvOG1XOnc.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] inputproto 2.1.99.4
The XI 2.2 (multitouch) protocol spec is now merged into master, so here's a new snapshot after the merge. Most of these commits were part of XI 2.1, the announce generator is a bit naïve. No functional changes in the input protocol since 2.1.99.3. The protocol does not require any configure flags or defines anymore. One bugfix: the dropped libXi version defines are reinstated so this version should work with older versions of libXi. Cyril Brulebois (1): specs: Fix tiny typo. Peter Hutterer (14): specs: clarify that Preferred scroll valuators are per scroll direction specs: We're up to version 2.1 now, say so specs: scroll events have no specific event type, state so. specs: smooth scrolling was added in 2.1, say so specs: typo fix specs: drop leftover from active_touches removal specs: clarify button state in touch events inputproto 2.1 Drop wrong comment for sourceid in TouchOwnershipEvents Reinstate libXi's version defines specs: remove parts of the Work in progress warning Remove --enable-unstable-protocol configure option specs: add XI 2.1 release to history section inputproto 2.1.99.4 git tag: inputproto-2.1.99.4 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.4.tar.bz2 MD5: 32f30ddfa1a69b142f3ed12ee501f5e8 inputproto-2.1.99.4.tar.bz2 SHA1: d269d2da4b4812a5dd49d5d678803489b24dd5b8 inputproto-2.1.99.4.tar.bz2 SHA256: 9446966f39596657bd7fe7bab715faf95b118bf9c5962becd67ed0a17572c5f2 inputproto-2.1.99.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.4.tar.gz MD5: 8a2c92e64cf94900ba86a91ff63d6fbc inputproto-2.1.99.4.tar.gz SHA1: 669a431a7ed9ba74e72592e225695b527faa9a85 inputproto-2.1.99.4.tar.gz SHA256: 5da1e3a09a6f0c661dfe6ca9a753ca74992bb36466f4bcfa0282e198ca438b98 inputproto-2.1.99.4.tar.gz pgp6GGS52momP.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libXi 1.4.5
libXi 1.4.4 caused requests to fail if the library was built against 2.1 or 2.2 protocol headers. Instead of requiring 2.0 for XI2 requests, the library required the protocol version (2.1 or 2.2 depending on the proto) and failed if the server did not support that version. This again caused virtually all XI2 requests to fail if you didn't happen to run an X server from git. The patch below hardcodes 2.0 for those requests that require 2.0, regardless of the protocol version. You are strongly enocuraged to update. This issue is not visible when built against inputproto 2.0.x Peter Hutterer (2): Don't use the protocol defines for 2.0 versioning. libXi 1.4.5 git tag: libXi-1.4.5 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.5.tar.bz2 MD5: 82dcdc76388116800a2c3ad969f510a4 libXi-1.4.5.tar.bz2 SHA1: 8ac24dec8e488f49fd6a6b256c815da9ceec9737 libXi-1.4.5.tar.bz2 SHA256: 22a99123229d22e6e1567c4cda0224a744475f427625d61b23d965157a86f1b5 libXi-1.4.5.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.5.tar.gz MD5: 47a383f7358489df0a57e9b89e3eb220 libXi-1.4.5.tar.gz SHA1: e50f5606b70555f61457f40067e6d8120dcb40ac libXi-1.4.5.tar.gz SHA256: b083c8d6094b9c9d856ebc46cb194d6f7038a729ed352a9c19bfb288ef576b46 libXi-1.4.5.tar.gz pgpPT440VgEdB.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] libXi 1.4.4
libXi 1.4.4 comes with two memory fixes that can cause crashes in clients. Commit Handle unknown device classes can only be triggered when libXi 1.4.x runs against the git X server. If the XIQueryDevice() reply contained classes unknown to libXi, we didn't allocate memory for these classes and ended up overwriting valid ones. Commit Fix duplicate sizeof in copy_classes fixes a typo, instead of malloc(X * sizeof(Y)) the code called malloc(sizeof(X * sizeof(Y))). This could lead to memory corruption. Peter Hutterer (8): man: Fix formatting in XGetFeedbackControl man: fix typo in XIQueryDevice man page Handle unknown device classes. man: fix #include for XIGrabButton man: XIGrabButton returns error codes, not status codes man: passive grabs return the number of failed modifier combinations Fix duplicate sizeof in copy_classes libXi 1.4.4 git tag: libXi-1.4.4 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.4.tar.bz2 MD5: 299f36c6d6a586ab33aa5c1d97d93078 libXi-1.4.4.tar.bz2 SHA1: e4ca1b45368214ba246bfad398ea087125c79f31 libXi-1.4.4.tar.bz2 SHA256: 939b25914d86496885b41b9e99969757ceed38c0e54e66a3993a269286ab5881 libXi-1.4.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.4.tar.gz MD5: 155d57405739a2ec95519116c11c8ee0 libXi-1.4.4.tar.gz SHA1: 72d99a4164b008232632d845a5afa8caecb9f733 libXi-1.4.4.tar.gz SHA256: bfb1cf00567a5a9bc2bd98b06bf77c33d18c48da9a62f2b413979803208384f9 libXi-1.4.4.tar.gz pgpKNdASUswab.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] inputproto 2.1
We haven't had any change requests to the 2.1 protocol changes and the 2.2 changes are about to be done soon too. Time for a release. inputproto contains the protocol specification and header files for the X Input Extension. This release introduces two new features: - smooth scrolling support allows devices to send scroll events through valuator information instead of the traditional button 4-7 clicks. - new raw event behaviour allows clients to listen to raw events from a device even if that device is currently grabbed For a description of the changes, see http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-smooth-scrolling.html http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-raw-events.html http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-xi2-defines.html http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-versioning.html Other changes include packaging fixes and miscellaneous fixes. Below is the full changelog since 2.0. Alexandre Julliard (1): XI2.h: Fix off-by-one error in the XIMaskLen definition. Chase Douglas (1): Include stdint.h Daniel Stone (2): Add XIPointerEmulated for emulated events Document smooth-scrolling support Fernando Carrijo (1): Fix typos in XIproto.txt Gaetan Nadon (14): .gitignore: use common defaults with custom section # 24239 configure.ac: AM_MAINTAINER_MODE missing #24238 configure.ac: deploy the new XORG_DEFAULT_OPTIONS #24242 Makefile.am: INSTALL file is missing or incorrect #24206 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 README: file created or updated #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES Add Red Had Copyright in the COPYING file. config: install and distribute XI2proto.txt XIproto.txt config: remove the pkgconfig pc.in file from EXTRA_DIST config: update AC_PREREQ statement to 2.60 specs: convert XI2proto.txt to html using asciidoc XI2proto.txt: fix whitespace issues XIproto.txt: fix whitespace issues Peter Hutterer (26): XI2proto.txt: fix up some request names. Define the error cases for XSetDeviceMode better. Spell out event types for XIDeviceEvent. Typo fix: GrabTypeFocusIn - GrabtypeFocusIn inputproto 2.0.1 Add minimal asciidoc syntax specs: move erroneous Errors: line to where it belongs specs: enable asciidoc parsing for XIproto.txt Add XI2-specific defines for grab and property requests Provide convenience defines for owner_events. specs: add a linebreak for asciidoc parsing Put a warning in about not adding any further libXi defines specs: ValuatorClass includes a mode specs: fix two typos in XI2proto.txt Bump to 2.0.99 Announce 2.1 availability through the XI_2_Major and XI_2_Minor defines XI2.1: send RawEvents at all times. Add sourceid to RawEvents (#34420) Move scroll information into a new class. inputproto 2.0.99.1 (first snapshot of 2.1) specs: clarify that Preferred scroll valuators are per scroll direction specs: We're up to version 2.1 now, say so specs: scroll events have no specific event type, state so. specs: smooth scrolling was added in 2.1, say so specs: typo fix inputproto 2.1 git tag: inputproto-2.1 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.tar.bz2 MD5: c4973f2e65a0ff9a283e665b31b96bb7 inputproto-2.1.tar.bz2 SHA1: 67b2c5af588d21a7dad2d60f9d3b1d148edb9d36 inputproto-2.1.tar.bz2 SHA256: b317361cdd09d79ba27f13d4e08adc793db27b491c4d513729e0d0312139 inputproto-2.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.tar.gz MD5: ba094ac09ddfcc4d3381193c2f189d80 inputproto-2.1.tar.gz SHA1: 9beeb9c29034d88fd35a7bd46c668f6781067661 inputproto-2.1.tar.gz SHA256: 02b35778bf4e2cb2a9b2c14a0c42e04180b71890fd7fcd371643c5f3d4df3467 inputproto-2.1.tar.gz pgpBCogKKGdA9.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] libXi 1.4.4
libXi 1.4.4 comes with two memory fixes that can cause crashes in clients. Commit Handle unknown device classes can only be triggered when libXi 1.4.x runs against the git X server. If the XIQueryDevice() reply contained classes unknown to libXi, we didn't allocate memory for these classes and ended up overwriting valid ones. Commit Fix duplicate sizeof in copy_classes fixes a typo, instead of malloc(X * sizeof(Y)) the code called malloc(sizeof(X * sizeof(Y))). This could lead to memory corruption. Peter Hutterer (8): man: Fix formatting in XGetFeedbackControl man: fix typo in XIQueryDevice man page Handle unknown device classes. man: fix #include for XIGrabButton man: XIGrabButton returns error codes, not status codes man: passive grabs return the number of failed modifier combinations Fix duplicate sizeof in copy_classes libXi 1.4.4 git tag: libXi-1.4.4 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.4.tar.bz2 MD5: 299f36c6d6a586ab33aa5c1d97d93078 libXi-1.4.4.tar.bz2 SHA1: e4ca1b45368214ba246bfad398ea087125c79f31 libXi-1.4.4.tar.bz2 SHA256: 939b25914d86496885b41b9e99969757ceed38c0e54e66a3993a269286ab5881 libXi-1.4.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.4.tar.gz MD5: 155d57405739a2ec95519116c11c8ee0 libXi-1.4.4.tar.gz SHA1: 72d99a4164b008232632d845a5afa8caecb9f733 libXi-1.4.4.tar.gz SHA256: bfb1cf00567a5a9bc2bd98b06bf77c33d18c48da9a62f2b413979803208384f9 libXi-1.4.4.tar.gz pgpMKRfNK7dqD.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] inputproto 2.1
We haven't had any change requests to the 2.1 protocol changes and the 2.2 changes are about to be done soon too. Time for a release. inputproto contains the protocol specification and header files for the X Input Extension. This release introduces two new features: - smooth scrolling support allows devices to send scroll events through valuator information instead of the traditional button 4-7 clicks. - new raw event behaviour allows clients to listen to raw events from a device even if that device is currently grabbed For a description of the changes, see http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-smooth-scrolling.html http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-raw-events.html http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-xi2-defines.html http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-versioning.html Other changes include packaging fixes and miscellaneous fixes. Below is the full changelog since 2.0. Alexandre Julliard (1): XI2.h: Fix off-by-one error in the XIMaskLen definition. Chase Douglas (1): Include stdint.h Daniel Stone (2): Add XIPointerEmulated for emulated events Document smooth-scrolling support Fernando Carrijo (1): Fix typos in XIproto.txt Gaetan Nadon (14): .gitignore: use common defaults with custom section # 24239 configure.ac: AM_MAINTAINER_MODE missing #24238 configure.ac: deploy the new XORG_DEFAULT_OPTIONS #24242 Makefile.am: INSTALL file is missing or incorrect #24206 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 README: file created or updated #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES Add Red Had Copyright in the COPYING file. config: install and distribute XI2proto.txt XIproto.txt config: remove the pkgconfig pc.in file from EXTRA_DIST config: update AC_PREREQ statement to 2.60 specs: convert XI2proto.txt to html using asciidoc XI2proto.txt: fix whitespace issues XIproto.txt: fix whitespace issues Peter Hutterer (26): XI2proto.txt: fix up some request names. Define the error cases for XSetDeviceMode better. Spell out event types for XIDeviceEvent. Typo fix: GrabTypeFocusIn - GrabtypeFocusIn inputproto 2.0.1 Add minimal asciidoc syntax specs: move erroneous Errors: line to where it belongs specs: enable asciidoc parsing for XIproto.txt Add XI2-specific defines for grab and property requests Provide convenience defines for owner_events. specs: add a linebreak for asciidoc parsing Put a warning in about not adding any further libXi defines specs: ValuatorClass includes a mode specs: fix two typos in XI2proto.txt Bump to 2.0.99 Announce 2.1 availability through the XI_2_Major and XI_2_Minor defines XI2.1: send RawEvents at all times. Add sourceid to RawEvents (#34420) Move scroll information into a new class. inputproto 2.0.99.1 (first snapshot of 2.1) specs: clarify that Preferred scroll valuators are per scroll direction specs: We're up to version 2.1 now, say so specs: scroll events have no specific event type, state so. specs: smooth scrolling was added in 2.1, say so specs: typo fix inputproto 2.1 git tag: inputproto-2.1 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.tar.bz2 MD5: c4973f2e65a0ff9a283e665b31b96bb7 inputproto-2.1.tar.bz2 SHA1: 67b2c5af588d21a7dad2d60f9d3b1d148edb9d36 inputproto-2.1.tar.bz2 SHA256: b317361cdd09d79ba27f13d4e08adc793db27b491c4d513729e0d0312139 inputproto-2.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.tar.gz MD5: ba094ac09ddfcc4d3381193c2f189d80 inputproto-2.1.tar.gz SHA1: 9beeb9c29034d88fd35a7bd46c668f6781067661 inputproto-2.1.tar.gz SHA256: 02b35778bf4e2cb2a9b2c14a0c42e04180b71890fd7fcd371643c5f3d4df3467 inputproto-2.1.tar.gz pgpcn2NFlTTUF.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: evdev input module and multiple X screen support
On Mon, Dec 12, 2011 at 09:02:29AM -0500, Curtis Rubel wrote: Peter, I have been looking at this for a while and have not been able to get my system setup correctly as it is a rather complex setup. I have 4 monitors on this system. The first one is NOT a touch screen and is at 800X600, the other 3 are touch screens at 1280X1024, with the center of those 3 rotated to portrait mode. I am not quite sure how to proceed looking at the examples provided since none of them really give me any idea of what to do about my first monitor which is not a touch device. you only set the matrix if you want a input device bound to an _area_ on the screen. so don't think of it in terms of monitors, think of it in terms of touchscreens - the first touchscreen should be mapped to area of the the second monitor from the left, etc. I am assuming that I still need to account for it in the equations, is that a valid assumption? #xinput list â¡ Virtual core pointer id=2[master pointer (3)] â â³ Virtual core XTEST pointer id=4[slave pointer (2)] â â³ TouchScreenLeft id=6[slave pointer (2)] â â³ TouchScreenCenterid=7[slave pointer (2)] â â³ TouchScreenRight id=8[slave pointer (2)] ⣠Virtual core keyboardid=3[master keyboard (2)] â³ Virtual core XTEST keyboard id=5[slave keyboard (3)] â³ Power Button id=9[slave keyboard (3)] â³ Power Button id=10 [slave keyboard (3)] â³ Logitech USB Keyboardid=11 [slave keyboard (3)] â³ Logitech USB Keyboardid=12 [slave keyboard (3)] #xinput list-props TouchScreenLeft Device 'TouchScreenLeft': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 #xinput list-props TouchScreenCenter Device 'TouchScreenCenter': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 #xinput list-props TouchScreenRight Device 'TouchScreenRight': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 So first to make it a little easier no rotation for now on #2: 0: 800/(800 + (3*1280) ) 00 0 600/1024 0 0 0 1 1: 1280/(800 + (3*1280) ) 0 800/(800 + (3*1280) ) 0 1024/10240 0 01 2: 1280/(800 + (3*1280) ) 0 800+1280/(800 + (3*1280) ) 0 1024/1024 0 0 0 1 3: 1280/(800 + (3*1280) ) 0 800 + (2*1280)/(800 + (3*1280) ) 0 1024/1024 0 0 0 1 Does that look about correct, because the math on the 3rd number or c2 from the equation examples does not seem to add up properly to equal a total of 1. I can't see anything wrong at a quick glance, though I suggest just trying with simple values (e.g. 0.5) first to make sure the mapping works at all (see below). c2 shouldn't usually add up to 1 since that'd be an offset of the display width - i don't think there's a use-case for that :) for the right-most screen, usually you'd want c0 + c2 to add up to 1. also, something I forgot in the first email: the matrix only works properly for RandR displays if you're using a released server version, only the git version supports this for traditional multihead. Cheers, Peter On 09.12.2011 23:37, Peter Hutterer wrote: On Fri, Dec 09, 2011 at 12:47:10PM -0500, Curtis Rubel wrote: Hello xorg... Can someone tell me if multiple X screen support is planned for the evdev input module? We have a number of multiple X screen systems here running Xorg using the older evtouch input library and from what I can see it appears this module is no longer supported and being replaced by the evdev module. Is this the case or has the evtouch input library just not been updated yet?? Any help in this matter would be greatly appreciated...as the touch screen vendor ELO does not support multiple USB touchscreens on a single system... input drivers don't do multi-screen handling (anymore), it's all handled by the server now. See the documentation here: http://wiki.x.org/wiki/XInputCoordinateTransformationMatrixUsage Cheers, Peter -- Curtis Rubel Senior Development Engineer Compro Computer Services, Inc. 105 East Drive - Melbourne, Florida, 32904 Phone: 321-727-2211 email: cru...@compro.net Web: http://www.compro.net An ISO
Re: evdev input module and multiple X screen support
On Fri, Dec 09, 2011 at 12:47:10PM -0500, Curtis Rubel wrote: Hello xorg... Can someone tell me if multiple X screen support is planned for the evdev input module? We have a number of multiple X screen systems here running Xorg using the older evtouch input library and from what I can see it appears this module is no longer supported and being replaced by the evdev module. Is this the case or has the evtouch input library just not been updated yet?? Any help in this matter would be greatly appreciated...as the touch screen vendor ELO does not support multiple USB touchscreens on a single system... input drivers don't do multi-screen handling (anymore), it's all handled by the server now. See the documentation here: http://wiki.x.org/wiki/XInputCoordinateTransformationMatrixUsage Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.11.99.1
On Sun, Nov 20, 2011 at 03:20:11PM -0800, Keith Packard wrote: We discussed doing regular releases from master, and Jeremy suggested (sensibly) that we just do them whenever there's a stable release. I completely spaced that plan, nor was I looking at the Google X.org calendar. In any case, here's the current state of master. It's missing a pull request from alanc -- there were a couple of build failures in that which I've replied back about and I expect that'll be fixed shortly. For those interested in helping out, here's the 1.12 release tracker. https://bugs.freedesktop.org/show_bug.cgi?id=40982 Anyone interested in helping clean up the release is encouraged to take a look at the outstanding bugs there. There's a slight snag about the 1.12 release schedule. I'm going biking in New Zealand next February, leaving on the 9th and not getting back until March 1st. So, we can either have the release done before I leave, or wait until I get back. It seems like the former might work a bit better, but it would mean pulling the release in to Feb 8th or so. Anyone have an opinion on the matter? We probably won't get X Input 2.2 done if the release is moved forward to Feb 8th. What's the date for the merge window end? Cheers, Peter ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: [ANNOUNCE] xorg-server 1.11.99.1
On Sun, Nov 27, 2011 at 07:29:53PM -0800, Keith Packard wrote: On Mon, 28 Nov 2011 11:39:31 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: We probably won't get X Input 2.2 done if the release is moved forward to Feb 8th. What's the date for the merge window end? If we followed the 1.11 schedule, the non-critical bug window would close three weeks earlier (Jan 18), and the merge window two months before that (Nov 18), which is now nine days past... If you think X Input 2.2 is nearly ready for merging , I'd say we should go for it and get that merged by Christmas, then plan on closing the non-critical bug window in the first week of February and then finish the release in the first week of March. If you don't think X Input 2.2 will be ready by then, we should probably just close out the merge window earlier, and plan on getting the release out the door by the time I go biking. I think Christmas is realistic for the merge. We're quite some way there, but pointer emulation and the resulting grab hilarity is still missing (Chase has worked on this while I was away but I haven't looked at the current state yet) Cheers, Peter ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: What will happen when the X server doesn't support XKB(XKEYBOARD)
On Mon, Nov 21, 2011 at 07:35:21PM +0800, Adam Q wrote: There is a X server for win32 which doesn't support XKB extension(I know it's unbelievable). There is something strange when I try to use the gnome-keyboard-properties and system-config-keyboard to change the X server's keyboard layout. When using gnome-keyboard-properties,the input of keyboard goes crazy and can't be used. When using system-config-keyboard the CLI just prints something like XKB extension unsupported and nothing changed including the keyboard layout. I tested serveral X server from the latest Xorg server in Arch and some old Xorg server in RHEL5.6/5.5 also with latest cygwin/X. All the servers I tested above can change the keyboard using these 2 GUI. I assume the problem is the lack of XKB extension but without XKB extension,the client should just send a lot of ChangeKeyboardLayout requests (and wireshark shows it really sends) to X server,and the layout should change even without the XKB extension and no crazy keyboard. How can I determine where the problem really is? possibly with xmodmap to get the keyboard mapping before/after and maybe xscope or something to snoop the protocol traffic. though a server without XKB support is not really high on the priority list for server or client developers and I expect this to be a rather untested scenario. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.11.99.1
On Sun, Nov 27, 2011 at 07:29:53PM -0800, Keith Packard wrote: On Mon, 28 Nov 2011 11:39:31 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: We probably won't get X Input 2.2 done if the release is moved forward to Feb 8th. What's the date for the merge window end? If we followed the 1.11 schedule, the non-critical bug window would close three weeks earlier (Jan 18), and the merge window two months before that (Nov 18), which is now nine days past... If you think X Input 2.2 is nearly ready for merging , I'd say we should go for it and get that merged by Christmas, then plan on closing the non-critical bug window in the first week of February and then finish the release in the first week of March. If you don't think X Input 2.2 will be ready by then, we should probably just close out the merge window earlier, and plan on getting the release out the door by the time I go biking. I think Christmas is realistic for the merge. We're quite some way there, but pointer emulation and the resulting grab hilarity is still missing (Chase has worked on this while I was away but I haven't looked at the current state yet) Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] inputproto 2.1.99.2
A second snapshot of the future inputprotocol 2.2. No major changes, but one field was removed from a request, the event numbers have changed and one field was renamed. Enough to warrant a new version and use the benefits of pkg-config. This is still considered unstable and required configure flags and #defines to build. The protocol may change in incompatible ways before the release. Chase Douglas (2): Fix Xi 2.x version comment in XI2.h Revert addition of active_touches to device events Peter Hutterer (3): XI2: swap (Raw)TouchUpdate and (Raw)TouchEnd XI2: Use touchid, not touch_id in XIAllowEvents inputproto 2.1.99.2 git tag: inputproto-2.1.99.2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.2.tar.bz2 MD5: cb167fd40b6e718d1369bc917e18b87e inputproto-2.1.99.2.tar.bz2 SHA1: 05ecf96bcc249e27d56ed9da45d606bb05ee6d0d inputproto-2.1.99.2.tar.bz2 SHA256: 7e84c6dd2754977975695f3f1f8284bb6c9c223a6517d202795c7be0c2d37d2f inputproto-2.1.99.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.2.tar.gz MD5: b26fd2bed51d8a106f9cb2348f9538fe inputproto-2.1.99.2.tar.gz SHA1: 3dee015521d7050657fa3fc830896bbcfadc3b82 inputproto-2.1.99.2.tar.gz SHA256: 22a3d9d7426f57860cabf845250b81ed8e3c1eb3f9e96f6ccf72594eed87865e inputproto-2.1.99.2.tar.gz pgp2Z7tMXWRZ1.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] libX11 1.4.99.1
A snapshot for the upcoming libX11 1.5. We've got a few bugfixes, new compose sequences and a large amount of cleanup in the specs. New macro/API added GetRequestSized to get a request of a specific size. Alan Coopersmith (2): Fix nomal - normal typo in several comments XlcSL.c: convert old-style function definitions to ANSI C89 style Alexander Polakov (1): XGrabKey manual page: change XAllowAccess to XAllowEvents in See Also Bodo Graumann (1): libX11: Fixing modifier key range in Xutil.h (Bug #21910) Choe Hwanjin (1): XIM: Make Xim handle NEED_SYNC_REPLY flag Derek Buitenhuis (1): makekeys: Fix build/target word size mismatch when cross-compiling Gaetan Nadon (34): nls: restructure charts as a single article with sections specs: build compose keys tables in specs/i18n/compose compose specs: generate chunked html libX11 specs: move /para above varaiablelist credits.xml: remove toc from Acknowledgments libX11 specs: review doclifter generated tables docbook.am: do not generate docs if docbook customization layer is missing docbook.am: explicitly list xmlto flags for each target docbook.am: add search path for local entities docbook.am: refactor common flags for xmlto and xsltproc compose: upgrade makefile to support olinking on chunked html docbook.am: embed css styles inside the HTML HEAD element docs: remove productnumber which is not used by default docs: remove orphan affiliation docs: use the fullrelvers; entity to set X11 release information docs: remove productnumber which is not used by default docs: use the fullrelvers; entity to set X11 release information specs: use appropriate markup for Copyright statements specs: remove orphan affiliation. specs: handle multiple sets of copyright notice/license/warranty docs: merge copyright holder under the same copyright notice specs: support multi licensed copyright notice and license text specs: The strandard name is still X Consortium Standard specs: fix The Open Group license text localedb: add release info to spec specs: support multi licensed copyright notice and license text localedb: restore X Consortium original legal text Framework: restore X Consortium copyright xtrans: restore X Consortium original legal text xim trans: restore Fujitsu copyright legal text XIM: refactor the multi licensing legal text XKB: provide adequate quotes for the license text libX11 specs: use copyright for first holder of multi license localedb specs: use copyright for first holder of multi license James Cloos (1): [nls] Fix typo/synco. Jeremy Huddleston (7): Use a configure check for seteuid Add additional compose sequences for pound sterling, yen, and cent (mixed case) Remove conflicting compose sequences for cent and colon Remove self-resolving aliases Fix potential uninitialized variable access in _XimMakeICAttrIDList Fix nobreakspace for pt_BR.UTF-8 Mark XKeycodeToKeysym as _X_DEPRECATED Marko Myllynen (1): Add new compose sequences Matt Dew (1): Cleanup IDs and links in doc Peter Hutterer (5): Add _XGetRequest as substitute for GetReq/GetReqExtra Switch GetEmptyReq and GetResReq to call _XGetRequest include: Add GetReqSized() for request buffers of specific size Use GetReqSized for GetReq and GetReqExtra libX11 1.4.99.1 Tollef Fog Heen (1): NLS: Add more vulgar fractions Xue Wei (1): mbtocs should not truncate input Yann Droneaud (2): Return name instead of value in XGetIMValues() and XSetIMValues() Return name instead of False in XSetICValues() git tag: libX11-1.4.99.1 http://xorg.freedesktop.org/archive/individual/lib/libX11-1.4.99.1.tar.bz2 MD5: 0e6e25d99cfb18c6631c6dc4ac411c69 libX11-1.4.99.1.tar.bz2 SHA1: 317e0112926926a52c13f56f71c1ec9e4540cf4d libX11-1.4.99.1.tar.bz2 SHA256: ede2880958814004d44a1c3a00e111d3175c5961fab0f6c58a7f43e1a3a404fc libX11-1.4.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libX11-1.4.99.1.tar.gz MD5: ada2a44824917c84dbac86541750581f libX11-1.4.99.1.tar.gz SHA1: 07dcc14205e51d5e6881e16c9acba7d06e7ac4aa libX11-1.4.99.1.tar.gz SHA256: b759bd86269d1564c6b1147dfe257435a82c030fb4ba347a830a3fcb428b3c11 libX11-1.4.99.1.tar.gz pgpZAJN6Setlk.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: your mail
On Thu, Nov 10, 2011 at 09:06:10AM -0800, Sebastian Glita wrote:
Hello,
Had 48 hours with no mouse movement since commit
b450efdf95999cad08de23ce069f04a66bdae24b to xorg/driver/xf86-input-evdev
Seems below #endif went one line too far:
@@ -1136,10 +1141,12 @@ EvdevAddRelValuatorClass(DeviceIntPtr device)
for (axis = REL_X; i MAX_VALUATORS axis = REL_MAX; axis++)
{
pEvdev-axis_map[axis] = -1;
+#ifndef HAVE_SMOOTH_SCROLLING
/* We don't post wheel events, so ignore them here too */
if (axis == REL_WHEEL || axis == REL_HWHEEL || axis == REL_DIAL)
continue;
if (!EvdevBitIsSet(pEvdev-rel_bitmask, axis))
+#endif
continue;
pEvdev-axis_map[axis] = i;
i++;
@@ -1168,6 +1175,14 @@ EvdevAddRelValuatorClass(DeviceIntPtr device)
Should be:
+#endif
if (!EvdevBitIsSet(pEvdev-rel_bitmask, axis))
thanks,
s.
Ooops, thanks, I pushed the fix to master,
a9cdb6590cdf72917cdfeb17e2fcc6a110b2c7d1
Cheers,
Peter
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
[ANNOUNCE] inputproto 2.1.99.2
A second snapshot of the future inputprotocol 2.2. No major changes, but one field was removed from a request, the event numbers have changed and one field was renamed. Enough to warrant a new version and use the benefits of pkg-config. This is still considered unstable and required configure flags and #defines to build. The protocol may change in incompatible ways before the release. Chase Douglas (2): Fix Xi 2.x version comment in XI2.h Revert addition of active_touches to device events Peter Hutterer (3): XI2: swap (Raw)TouchUpdate and (Raw)TouchEnd XI2: Use touchid, not touch_id in XIAllowEvents inputproto 2.1.99.2 git tag: inputproto-2.1.99.2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.2.tar.bz2 MD5: cb167fd40b6e718d1369bc917e18b87e inputproto-2.1.99.2.tar.bz2 SHA1: 05ecf96bcc249e27d56ed9da45d606bb05ee6d0d inputproto-2.1.99.2.tar.bz2 SHA256: 7e84c6dd2754977975695f3f1f8284bb6c9c223a6517d202795c7be0c2d37d2f inputproto-2.1.99.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.2.tar.gz MD5: b26fd2bed51d8a106f9cb2348f9538fe inputproto-2.1.99.2.tar.gz SHA1: 3dee015521d7050657fa3fc830896bbcfadc3b82 inputproto-2.1.99.2.tar.gz SHA256: 22a3d9d7426f57860cabf845250b81ed8e3c1eb3f9e96f6ccf72594eed87865e inputproto-2.1.99.2.tar.gz pgpiwR7frf6Qt.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libX11 1.4.99.1
A snapshot for the upcoming libX11 1.5. We've got a few bugfixes, new compose sequences and a large amount of cleanup in the specs. New macro/API added GetRequestSized to get a request of a specific size. Alan Coopersmith (2): Fix nomal - normal typo in several comments XlcSL.c: convert old-style function definitions to ANSI C89 style Alexander Polakov (1): XGrabKey manual page: change XAllowAccess to XAllowEvents in See Also Bodo Graumann (1): libX11: Fixing modifier key range in Xutil.h (Bug #21910) Choe Hwanjin (1): XIM: Make Xim handle NEED_SYNC_REPLY flag Derek Buitenhuis (1): makekeys: Fix build/target word size mismatch when cross-compiling Gaetan Nadon (34): nls: restructure charts as a single article with sections specs: build compose keys tables in specs/i18n/compose compose specs: generate chunked html libX11 specs: move /para above varaiablelist credits.xml: remove toc from Acknowledgments libX11 specs: review doclifter generated tables docbook.am: do not generate docs if docbook customization layer is missing docbook.am: explicitly list xmlto flags for each target docbook.am: add search path for local entities docbook.am: refactor common flags for xmlto and xsltproc compose: upgrade makefile to support olinking on chunked html docbook.am: embed css styles inside the HTML HEAD element docs: remove productnumber which is not used by default docs: remove orphan affiliation docs: use the fullrelvers; entity to set X11 release information docs: remove productnumber which is not used by default docs: use the fullrelvers; entity to set X11 release information specs: use appropriate markup for Copyright statements specs: remove orphan affiliation. specs: handle multiple sets of copyright notice/license/warranty docs: merge copyright holder under the same copyright notice specs: support multi licensed copyright notice and license text specs: The strandard name is still X Consortium Standard specs: fix The Open Group license text localedb: add release info to spec specs: support multi licensed copyright notice and license text localedb: restore X Consortium original legal text Framework: restore X Consortium copyright xtrans: restore X Consortium original legal text xim trans: restore Fujitsu copyright legal text XIM: refactor the multi licensing legal text XKB: provide adequate quotes for the license text libX11 specs: use copyright for first holder of multi license localedb specs: use copyright for first holder of multi license James Cloos (1): [nls] Fix typo/synco. Jeremy Huddleston (7): Use a configure check for seteuid Add additional compose sequences for pound sterling, yen, and cent (mixed case) Remove conflicting compose sequences for cent and colon Remove self-resolving aliases Fix potential uninitialized variable access in _XimMakeICAttrIDList Fix nobreakspace for pt_BR.UTF-8 Mark XKeycodeToKeysym as _X_DEPRECATED Marko Myllynen (1): Add new compose sequences Matt Dew (1): Cleanup IDs and links in doc Peter Hutterer (5): Add _XGetRequest as substitute for GetReq/GetReqExtra Switch GetEmptyReq and GetResReq to call _XGetRequest include: Add GetReqSized() for request buffers of specific size Use GetReqSized for GetReq and GetReqExtra libX11 1.4.99.1 Tollef Fog Heen (1): NLS: Add more vulgar fractions Xue Wei (1): mbtocs should not truncate input Yann Droneaud (2): Return name instead of value in XGetIMValues() and XSetIMValues() Return name instead of False in XSetICValues() git tag: libX11-1.4.99.1 http://xorg.freedesktop.org/archive/individual/lib/libX11-1.4.99.1.tar.bz2 MD5: 0e6e25d99cfb18c6631c6dc4ac411c69 libX11-1.4.99.1.tar.bz2 SHA1: 317e0112926926a52c13f56f71c1ec9e4540cf4d libX11-1.4.99.1.tar.bz2 SHA256: ede2880958814004d44a1c3a00e111d3175c5961fab0f6c58a7f43e1a3a404fc libX11-1.4.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libX11-1.4.99.1.tar.gz MD5: ada2a44824917c84dbac86541750581f libX11-1.4.99.1.tar.gz SHA1: 07dcc14205e51d5e6881e16c9acba7d06e7ac4aa libX11-1.4.99.1.tar.gz SHA256: b759bd86269d1564c6b1147dfe257435a82c030fb4ba347a830a3fcb428b3c11 libX11-1.4.99.1.tar.gz pgpZhcZ543376.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] libXi 1.4.99.1
On Wed, Nov 09, 2011 at 07:24:08PM +1100, Russell Shaw wrote: On 09/11/11 12:16, Peter Hutterer wrote: A month late but I just noticed that I never sent an announcement out for this. libXi is the first snapshot for XI 2.1 support. At this point I consider it unlikely that any major protocol changes will happen to the smooth scrolling support. If you're working on a toolkit or similar, I highly recommend to start using the new stuff while we can still change it to fit your expectations better. Hi, I posted this message 4-Nov-2010: quote In XInput2, when i get a XI_HierarchyChanged event after plugging in another mouse, is there a way to get a unique identifier for each device such as a brand and model number? The Device Product ID property contain vendor and product ID (if those are set by the driver). Cheers, Peter When i start my program that uses two mice for different functions (one in each hand), it would be useful for them both to be assigned the correct role whenever the program is started, regardless of whatever other devices have been plugged in since the last session. unquote I'm not currently working on mouse stuff, but i will again sometime, and will use more than one pointer device simultaneously for CAD programs. Brand and model number and also the port the pointer is plugged into would be useful, in case both devices are the same model. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: peter.hutte...@who-t.net ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libXi 1.4.99.1
A month late but I just noticed that I never sent an announcement out for this. libXi is the first snapshot for XI 2.1 support. At this point I consider it unlikely that any major protocol changes will happen to the smooth scrolling support. If you're working on a toolkit or similar, I highly recommend to start using the new stuff while we can still change it to fit your expectations better. Alan Coopersmith (3): Move Xinput server API documentation from libXi to xserver Fix the FIXME output in man page .TH macros generated by asciidoc Make shadow man pages generated by asciidoc work with Solaris man Gaetan Nadon (13): Documentation: add Docbook external references support make: remove unneeded AM_V_GEN silent rule directive. make: use AM_V_at rather than AM_V_GEN to prefix the mv command Install target dbs alongside generated documents Install xml versions of specs even if HAVE_XMLTO is false docbook.am: global maintenance update - entities, images and olinking docbook.am: embed css styles inside the HTML HEAD element docs: remove productnumber which is not used by default docs: use the fullrelvers; entity to set X11 release information inputlib: fix copyright statements inputlib: prefix 1.0 with the word Version inputlib: restore original title X Input Device Extension Library specs: refactor and complete copyright legal text Jeremy Huddleston (1): Use AM_CPPFLAGS to use in tree headers before installed headers Matt Dew (2): Add id attributes to funcsynopsis to allow other docs to olink to them. 1 - fix the capitalization of the ID attriutes to match either the Matthieu Herrb (1): Fix XISelectEvents on 64 bits, strict alignement architectures. Peter Hutterer (26): Allocate enough memory for raw events + extra data. XIChangeHierarchy: Return Success early if no actual changes are requested. Remove a few unused assignments. man: fix typo, layout in XGetExtensionVersion.man Silence compiler warning in XListDProp.c Silence compiler warning due to differnent event conversion procs man: fix missing comma in XIGrabEnter man page Use Data, not Data32 in XIPassiveGrabDevice man: Fix wrong event names in XIGrabButton. man: Fix typo in XIChangeProperty Bump to 1.4.99 man: Fix formatting in XGetFeedbackControl Add XI2 library-internal array offsets to XIint.h Don't use the protocol defines for 2.0 versioning. Handle unknown device classes. man: fix typo in XIQueryDevice man page man: update property and grab man pages for new constants Handle unknown device classes. man: fix typo in XIQueryDevice man page man: update property and grab man pages for new constants Require inputproto 2.0.99.1 or later Support XI 2.1 internally Support XI 2.1 XIScrollClass Use a separate nclasses variable in XIQueryDevice Remove superfluous assignment of lib-classes in XIQueryDevices. Bump to 1.4.99.1 git tag: libXi-1.4.99.1 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.99.1.tar.bz2 MD5: 4e9dedaa2fe2561f9f0161d5c14db804 libXi-1.4.99.1.tar.bz2 SHA1: 369ac8f926411f67d43529e987b8f02662c0dd46 libXi-1.4.99.1.tar.bz2 SHA256: fa3ef44096d73a2578cc0548f870425fb4d6f3a406adcbdd7389de2bd66363a4 libXi-1.4.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.99.1.tar.gz MD5: 93edd0abf62ee8cb5510f5576d941a76 libXi-1.4.99.1.tar.gz SHA1: ee3319a8ad7b4cc2100117c0e053be1fd2a7c376 libXi-1.4.99.1.tar.gz SHA256: 37c98df8e05b0eddc05b5f444b0aae34265b6b72ab1131b57e843a3886f8f6b8 libXi-1.4.99.1.tar.gz pgpGgjwYiGcCo.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] libXi 1.4.99.1
A month late but I just noticed that I never sent an announcement out for this. libXi is the first snapshot for XI 2.1 support. At this point I consider it unlikely that any major protocol changes will happen to the smooth scrolling support. If you're working on a toolkit or similar, I highly recommend to start using the new stuff while we can still change it to fit your expectations better. Alan Coopersmith (3): Move Xinput server API documentation from libXi to xserver Fix the FIXME output in man page .TH macros generated by asciidoc Make shadow man pages generated by asciidoc work with Solaris man Gaetan Nadon (13): Documentation: add Docbook external references support make: remove unneeded AM_V_GEN silent rule directive. make: use AM_V_at rather than AM_V_GEN to prefix the mv command Install target dbs alongside generated documents Install xml versions of specs even if HAVE_XMLTO is false docbook.am: global maintenance update - entities, images and olinking docbook.am: embed css styles inside the HTML HEAD element docs: remove productnumber which is not used by default docs: use the fullrelvers; entity to set X11 release information inputlib: fix copyright statements inputlib: prefix 1.0 with the word Version inputlib: restore original title X Input Device Extension Library specs: refactor and complete copyright legal text Jeremy Huddleston (1): Use AM_CPPFLAGS to use in tree headers before installed headers Matt Dew (2): Add id attributes to funcsynopsis to allow other docs to olink to them. 1 - fix the capitalization of the ID attriutes to match either the Matthieu Herrb (1): Fix XISelectEvents on 64 bits, strict alignement architectures. Peter Hutterer (26): Allocate enough memory for raw events + extra data. XIChangeHierarchy: Return Success early if no actual changes are requested. Remove a few unused assignments. man: fix typo, layout in XGetExtensionVersion.man Silence compiler warning in XListDProp.c Silence compiler warning due to differnent event conversion procs man: fix missing comma in XIGrabEnter man page Use Data, not Data32 in XIPassiveGrabDevice man: Fix wrong event names in XIGrabButton. man: Fix typo in XIChangeProperty Bump to 1.4.99 man: Fix formatting in XGetFeedbackControl Add XI2 library-internal array offsets to XIint.h Don't use the protocol defines for 2.0 versioning. Handle unknown device classes. man: fix typo in XIQueryDevice man page man: update property and grab man pages for new constants Handle unknown device classes. man: fix typo in XIQueryDevice man page man: update property and grab man pages for new constants Require inputproto 2.0.99.1 or later Support XI 2.1 internally Support XI 2.1 XIScrollClass Use a separate nclasses variable in XIQueryDevice Remove superfluous assignment of lib-classes in XIQueryDevices. Bump to 1.4.99.1 git tag: libXi-1.4.99.1 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.99.1.tar.bz2 MD5: 4e9dedaa2fe2561f9f0161d5c14db804 libXi-1.4.99.1.tar.bz2 SHA1: 369ac8f926411f67d43529e987b8f02662c0dd46 libXi-1.4.99.1.tar.bz2 SHA256: fa3ef44096d73a2578cc0548f870425fb4d6f3a406adcbdd7389de2bd66363a4 libXi-1.4.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.99.1.tar.gz MD5: 93edd0abf62ee8cb5510f5576d941a76 libXi-1.4.99.1.tar.gz SHA1: ee3319a8ad7b4cc2100117c0e053be1fd2a7c376 libXi-1.4.99.1.tar.gz SHA256: 37c98df8e05b0eddc05b5f444b0aae34265b6b72ab1131b57e843a3886f8f6b8 libXi-1.4.99.1.tar.gz pgp5Fiii4wvq6.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Simulating a mouse click
On Wed, Nov 02, 2011 at 03:27:42PM +0100, Markus Kramer wrote: Hi, I'm attempting to use xlib to simulate a series of mouse clicks in an application (gedit). I found some posts that describe how to do this and it essentially works. I can do left clicks on buttons and so on. But if I generate a click on the menu bar, a menu opens and something breaks and no further ButtonPress/ButtonRelease events that I send will be processed by the application. When debugging it with xtrace I noticed that my events look slightly different than real left click events. Real: ButtonPress(4) [1]button=left button(0x01) [4]time=0x03752355 [8]root=0x0102 [12]event=0x01a3 [16]child=None(0x) [20]root-x=428 [22]root-y=33 [24]event-x=295 [26]event-y=10 state=0 [30]same-screen=true(0x01) My simulated event: SendEvent [1]propagate=true(0x01) [4]destination=PointerWindow(0x) event-mask=ButtonPress ButtonPress(4) [1]button=left button(0x01) [4]time=0x [8]root=0x0102 [12]event=0x012000a3 [16]child=None(0x) [20]root-x=407 [22]root-y=40 [24]event-x=274 [26]event-y=19 state=0 [30]same-screen=true(0x01) The field event of the real event says 0x01a3 mine is 0x012000a3. What is this event field about? It is not part of the ButtonPress struct. event is the window the event happens on. once you send a button down on a menu, the client usually grabs the device that sent the event and the event window from then on is the grab window, not necessarily the window underneath the cursor. If you're tyring to emulate click events, I recommend to use the XTest extension instead, it's much simpler to handle. Cheers, Peter This is the code that I use to simulate a left click: --- XEvent event; memset(event, 0, sizeof(XEvent)); XWindowAttributes attr; XGetWindowAttributes(dpy, windowId, attr); event.type = ButtonPress; event.xbutton.same_screen = TRUE; event.xbutton.root = root; event.xbutton.window = windowId; event.xbutton.subwindow = None; event.xbutton.x = x; event.xbutton.y = y; event.xbutton.x_root = attr.x + x; event.xbutton.y_root = attr.y + y; event.xbutton.state = 0; event.xbutton.button = Button1; XSendEvent(dpy, PointerWindow, True, ButtonPressMask, event); XFlush(dpy); // the same for ButtonRelease, with modified state and mask -- Thanks in advance. Markus ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: peter.hutte...@who-t.net ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Missing events sometimes
On Tue, Oct 25, 2011 at 10:16:17AM +0200, Olivier Fourdan wrote: I have been facing a bug in the xfce [1] window manager xfwm4 [2], for a very long time, no doubt the fault is with my code yet I fail to find the fix. Sometimes, when the system is heavily loaded and/or swapping intensively, the event loop does not get the ButtonReleasse or KeyRelease events it's waiting to exit the event loop. The logic used in the code is the following: 1. For keyboard, it installs a passive grab in sync mode on keyboard, ie: XGrabKey (dpy, keycode, modifier, w, TRUE, GrabModeAsync, GrabModeSync); 2. For buttons, same with Sync mode on pointer XGrabButton (dpy, button, modifier, w, FALSE, ButtonPressMask|ButtonReleaseMask, GrabModeSync, GrabModeAsync, None, None); 3. Then when the user activates a keyboard shortcut or moves a window usign the mouse, the window manager installs an active grab on the keyboard / pointer using the timestamp of the event: XGrabKeyboard (dpy, root, TRUE, GrabModeAsync, GrabModeAsync, timestamp) or XGrabPointer (dpy, root, FALSE, PointerMotionMask | ButtonMotionMask | ButtonReleaseMask | LeaveWindowMask, GrabModeAsync, GrabModeAsync, root, cursor, timestamp); 4. Then enters an event loop processing events, until a KeyRelease event (in the case of a keyboard shortcut) or a ButtonRelease is received (in the case of a mouse op). Using this logic, the code sometimes (when the system is loaded or swapping) remains in the event loop because the ButtonRelease or KeyRelease event is not received in the event loop, so I guess it's consumed somehow before the code enters the event loop, but how? I'm not sure on the actual code but there's a race condition for both - if the release event happens before the server receives/processes the GrabKey/Pointer request you may drop the event on the floor. This shouldn't happen since you should get it delivered based on the passive grab either way but there's a chance the client drops it. Try swapping the passive grab to sync and see if that avoids it. As I said, there's probably a flaw somewhere in the logic, but I fail to find it (also because of the nature of the probl;em it's quite hard to reproduce and therefore investigate and test), so I am open to any suggestion... put a delay in before XGrabPointer in the client and click fast (so that the release happens before the request). this way you can easily verify if it is that race condition or something else. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: remapping XInput axes
On Mon, Oct 24, 2011 at 01:59:50PM +0200, Tamas Papp wrote: On Mon, 24 Oct 2011, Peter Hutterer wrote: On Fri, Oct 21, 2011 at 02:45:06PM +0200, Tamas Papp wrote: Hi, I just purchased an Intellipen Pro digital pen. It shows up fine in xinput list: [...] and button events are detected, but the cursor doesn't move. xinput test reveals that the X and Y axes are a[2] and a[3]: [...] Device 'EPOS EPOS Pen Digitizer.': Device Enabled (132): 1 Coordinate Transformation Matrix (134): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 Device Accel Profile (257): 0 Device Accel Constant Deceleration (258): 1.00 Device Accel Adaptive Deceleration (259): 1.00 Device Accel Velocity Scaling (260):10.00 Evdev Axis Inversion (261): 0, 0 Evdev Axis Calibration (262): no items Evdev Axes Swap (263): 0 Axis Labels (264): Abs X (254), Abs Y (255), Abs Z (275), Abs Rotary X (276), Abs Pressure (485), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285) Fairly common issue. The kernel needs a fix to enable HID_QUIRK_MULTI_INPUT for this device. Hi Peter, Thanks, that put me on the right track. I just had to create /etc/hal/fdi/policy/90-intellipen-pro.fdi with the contents ?xml version=1.0 encoding=UTF-8? deviceinfo version=0.2 device !-- Intellipen Pro -- match key=usb_device.vendor_id int=0x188c match key=usb_device.product_id int=0x221 merge key=input.x11_driver type=stringevdev/merge /match /match /device /deviceinfo and /etc/modprobe.d/intellipen.conf with options usbhid quirks=0x188c:0x0221:0x0040 and the device works perfectly. Where should I submit this information so that it gets incorporated to future updates so that others can just plug it in and have it work automatically? kernel bugzilla. I'd be easy enough to knock up a kernel patch that adds the quirk for this particular device, so if you can find the time to do that you're most likely to see the change happen. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: remapping XInput axes
On Fri, Oct 21, 2011 at 02:45:06PM +0200, Tamas Papp wrote: Hi, I just purchased an Intellipen Pro digital pen. It shows up fine in xinput list: [...] and button events are detected, but the cursor doesn't move. xinput test reveals that the X and Y axes are a[2] and a[3]: [...] Device 'EPOS EPOS Pen Digitizer.': Device Enabled (132): 1 Coordinate Transformation Matrix (134): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 Device Accel Profile (257): 0 Device Accel Constant Deceleration (258): 1.00 Device Accel Adaptive Deceleration (259): 1.00 Device Accel Velocity Scaling (260):10.00 Evdev Axis Inversion (261): 0, 0 Evdev Axis Calibration (262): no items Evdev Axes Swap (263): 0 Axis Labels (264): Abs X (254), Abs Y (255), Abs Z (275), Abs Rotary X (276), Abs Pressure (485), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285), Abs Misc (285) Fairly common issue. The kernel needs a fix to enable HID_QUIRK_MULTI_INPUT for this device. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xinput - core pointer - Transformation?
On Thu, Oct 13, 2011 at 01:51:26PM +0200, Roman Seidl wrote: Thnaks for answering my request. Well it does not seem to be a Problem with Xournal - it ist the same with the current stable and the development version. Furthermore it ist the same problem with GIMP when i activate the Xinput. So is there any information onf how the pointer gets transformed? dix/getevents.c:transformAbsolute() in the server. The theory is that for any coordinate x/y that the driver posts the actual event coordinates given a matrix M are x(m)/y(m). So you should never see the original coordinates. Simplest example, a driver with range 0..100 that has a matrix mapping to the left 50% should only ever have 0..50 in the events. Provided the server does this correctly, the rest is in the client side. Cheers, Peter best regards roman Am 2011-09-30 07:20, schrieb Peter Hutterer: On Wed, Sep 28, 2011 at 11:36:41PM +0200, roman wrote: Hi! I have a tablet and i want to use an external monitor that covers just a part of the screen. This is no problem concering xrandr as i can set a scale and a position. The problem is with the pen. The pen core pointer is automatically postioned the right way - even in this situation. But no transformation matrix whatsoever is set in the xinput settings for the device. Sounds nice BUT I want to use direct xinput for using xournal. So i would like to modify the Transformation matrix. If i do so the xinput can be set to be in line with the monitors - but then the core pointer is wrong. How is the xinput transformed into postions on screen for the core pointer? Is there any way to get infos on the transformation that takes place? Is it possible to modify it? I don't quite understand. Changing the device matrix should also change the XI coordinates and map them into the same range. What isn't working here? Does xournal scale somehow differently again? Cheers, Peter -- mail ro...@granul.at webhttp://granul.at tel+43-650-2041643 jabber r...@jabber.org ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: wireless keyboard and mouse doesn't work on multiseat
On Mon, Oct 10, 2011 at 03:11:40PM -0700, stompdagg...@yahoo.com wrote: hello again. I've replaced the wireless combo with a logitech mk250, current behavior is that the reaction of keyboard is mostly delayed (major delay) and the mouse is jerky but not like it was with the ms combo. what are the odds this is a kdm issue as I use kdm to login? don't know, I suspect this is an unrelated issue. the only times I notice my mouse being jerky is when the machine is swapping. Cheers, Peter From: Peter Hutterer peter.hutte...@who-t.net To: stompdagg...@yahoo.com stompdagg...@yahoo.com Cc: xorg@lists.freedesktop.org xorg@lists.freedesktop.org Sent: Tuesday, September 20, 2011 8:24 AM Subject: Re: wireless keyboard and mouse doesn't work on multiseat On Mon, Sep 19, 2011 at 09:58:12PM -0700, stompdagg...@yahoo.com wrote: Hello, Thanks for the response, I've tried using the mouse event, the behavior is the same. maybe your udev rules are messed up? the ioctl should succeed on any event device. Cheers, Peter From: Peter Hutterer peter.hutte...@who-t.net To: stompdagg...@yahoo.com stompdagg...@yahoo.com Cc: xorg@lists.freedesktop.org xorg@lists.freedesktop.org Sent: Tuesday, September 20, 2011 2:45 AM Subject: Re: wireless keyboard and mouse doesn't work on multiseat On Tue, Sep 13, 2011 at 10:04:05PM -0700, stompdagg...@yahoo.com wrote: Hello everyone, I have a strange problem, I've build a dual multiseat configuration to a gentoo installation which is as follows: seat0 is composed of a ati3650, lg 19' screen, logitech usb mouse and ibm keyboard. seat1 is composed of a ati5450, lg lcd 37' tv (usng 10m hdmi cable), ms wireless 1000 keyboard and wireless 800 mouse combo. when booting the config, seat0 is working ok but the input in seat1 doesn't work, there is a distance between the seat and the computer (5-7 meters) but when I sit just beside the computer and tries the input it still doesn't work. I've tried other usb sockets, I was able to find one which results in a extremly delayed keyboard and jerky mouse but this happens only of I start to move the mouse the minute I see the cursor, if I don't then it won't work at all. if I drop to console, both keyboards work and if I boot in single seat, both mouses works. here are some configs: .config: http://paste.pocoo.org/show/473571/ /etc/X11/xorg.conf: http://paste.pocoo.org/show/473574/ /usr/share/config/kdm/kdmrc: http://paste.pocoo.org/show/473575/ /var/log/Xorg.0.log: http://paste.pocoo.org/show/473576/ /var/log/Xorg.1.log: http://paste.pocoo.org/show/473577/ emerge --info x11-base/xorg-server: http://paste.pocoo.org/show/473578/ I have at home (at work now) another log in which I see this for the seat1: [ 18.783] (II) Using input driver 'evdev' for 'Mouse1' [ 18.783] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so [ 18.783] (**) Option CorePointer [ 18.783] (**) Mouse1: always reports core events [ 18.783] (**) Mouse1: Device: /dev/input/by-id/usb-Microsoft_Microsoft®_2.4GHz_Transceiver_v8.0-mouse this should be the event-mouse file, that should fix it. Cheers, Peter [ 18.783] (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device [ 18.811] (EE) PreInit returned 8 for Mouse1 [ 18.811] (II) UnloadModule: evdev [ 18.811] (II) Unloading evdev when I'll get home, I'll provide it too Thanks for the help guys. : , . An wise Scandinavian old man once said: in the end, everything is going to be alright ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: peter.hutte...@who-t.net ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: stompdagg...@yahoo.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: stompdagg...@yahoo.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Building NV driver from git
On Sun, Oct 09, 2011 at 05:07:47PM -0500, Harry Putnam wrote: Running Debian wheezy After cloning the git repo for: git://anongit.freedesktop.org/xorg/driver/xf86-video-nv I got a slug of errors when running ./autogen.sh autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal configure.ac:33: error: must install xorg-macros 1.8 or later before running autoconf/autogen configure.ac:33: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: /usr/bin/autom4te failed with exit status: 1 autoreconf: aclocal failed with exit status: 1 So is it just the macros I must have? And where are they obtained git://anongit.freedesktop.org/git/xorg/util/macros Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Ctl+C logout in multiseat
On Wed, Oct 05, 2011 at 02:38:59AM +0330, masoud javadieh wrote: Ctl+c log out multiseat in fedora14, x server 1.10.3. Any solution ? sounds like the console isn't set to raw mode and the ctrl+c is delivered to the tty, cancelling the X server process. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xinput - core pointer - Transformation?
On Wed, Sep 28, 2011 at 11:36:41PM +0200, roman wrote: Hi! I have a tablet and i want to use an external monitor that covers just a part of the screen. This is no problem concering xrandr as i can set a scale and a position. The problem is with the pen. The pen core pointer is automatically postioned the right way - even in this situation. But no transformation matrix whatsoever is set in the xinput settings for the device. Sounds nice BUT I want to use direct xinput for using xournal. So i would like to modify the Transformation matrix. If i do so the xinput can be set to be in line with the monitors - but then the core pointer is wrong. How is the xinput transformed into postions on screen for the core pointer? Is there any way to get infos on the transformation that takes place? Is it possible to modify it? I don't quite understand. Changing the device matrix should also change the XI coordinates and map them into the same range. What isn't working here? Does xournal scale somehow differently again? Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Are elographics working now?
On Sat, Sep 10, 2011 at 03:03:26AM +0400, Ivan Afonichev wrote: I don't see any usage of calibration options MaxX MinX MaxY MinY in http://cgit.freedesktop.org/xorg/driver/xf86-input-elographics/tree/src/xf86Elo.c after this commit http://cgit.freedesktop.org/xorg/driver/xf86-input-elographics/commit/src/xf86Elo.c?id=447f547fbb7d11ec56ea578292908192175b3828 IIRC this function hasn't been called by the driver since server 1.4 or 1.5, so it's likely this has been broken since around 2008. no reason it can't be fixed but it's unlikely since the driver is barely maintained as it is. we generally recommend using a kernel driver and then evtest on top. Also my elographics(GeneralTouch) device are shown as [floating slave] in xinput list. When I xinput reattach it, it acts as not calibrated. This would suggest a configuration issue, you probably have CoreEvents off. Cheers, Peter I think we should add something like int width = priv-max_x - priv-min_x; int height = priv-max_y - priv-min_y; cur_x = (priv-screen_width * (cur_x - priv-min_x)) / width; cur_y = (priv-screen_height - (priv-screen_height * (cur_y - priv-min_y)) / height); in xf86EloReadInput(InputInfoPtr pInfo) or use xf86ScaleAxis() or use correct screen and max/min values in this stuff /* I will map coordinates myself */ InitValuatorAxisStruct(dev, 0, axis_labels[0], -1, -1, 9500, 0 /* min_res */, 9500 /* max_res */, Absolute); InitValuatorAxisStruct(dev, 1, axis_labels[1], -1, -1, 10500, 0 /* min_res */, 10500 /* max_res */, Absolute); I'am going to try first way soon. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: peter.hutte...@who-t.net ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [PATCH] xserver: add udev/systemd multi-seat support
On Sun, Sep 04, 2011 at 10:44:21AM +0200, Colin Guthrie wrote: 'Twas brillig, and Lennart Poettering at 17/07/11 02:33 did gyre and gimble: Add support for multi-seat-aware input device hotplugging. This implements the multi-seat scheme explained here: http://www.freedesktop.org/wiki/Software/systemd/multiseat This introduces a new X server switch -seat which allows configuration of the seat to enumerate hotplugging devices on. If specified the value of this parameter will also be exported as root window property Xorg_Seat. To properly support input hotplugging devices need to be tagged in udev according to the seat they are on. Untagged devices are assumed to be on the default seat seat0. If no -seat parameter is passed only devices on seat0 are used. This means that the new scheme is perfectly compatible with existing setups which have no tagged input devices. This also optimizes the udev code in away that is beneficial for systems that do not support new udev/systemd style multi-seat: the patch makes use of libudev functions to limit enumerating/monitoring of devices to actual input devices. This should speed up start-up and minimize wake-ups, since we will only enumerate/monitor the devices we are interested in instead of all devices on the machine and all events they generate. Finally, this also unifies the code paths for the udev change and add events, since these should be handled the same way in order to be robust to udevadm trigger calls, or lost netlink messages. This also simplifies the code. Note that the -seat switch takes a completely generic identifier, and that it has no effect on non-Linux systems. In fact, on other OSes a completely different identifier scheme for seats could be used but still be exposed with the Xorg_Seat and -seat. I tried to follow the coding style of the surrounding code blocks if there was any one could follow. I didn't see any feedback on this patch. Did anything more happen regarding it? Does it need a bug opened? it's in my -next branch which will be merged as soon as I get reviewed-by for the smooth scrolling patches here: http://lists.freedesktop.org/archives/xorg-devel/2011-September/024861.html Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.5.0
Only one change over the snapshot to fix up the pressure and finger width ranges. As said previously, this release doesn't bring anything big, the next version will have some interesting features though. Cheers, Peter Alexandr Shadchin (1): The correct maximum values for pressure and finger width Peter Hutterer (1): synaptics 1.5.0 git tag: xf86-input-synaptics-1.5.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.0.tar.bz2 MD5: 41ee749ecbfef98f7fba708cb2afae87 xf86-input-synaptics-1.5.0.tar.bz2 SHA1: 7373c1e3f02bf7e18f71b65762a982d907b4a053 xf86-input-synaptics-1.5.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.0.tar.gz MD5: a776801c979413c2170f084986a3a8d7 xf86-input-synaptics-1.5.0.tar.gz SHA1: 17ba02488cc1497c8d83b032fd324dca5fa1c62b xf86-input-synaptics-1.5.0.tar.gz pgp2e2MDkjaBM.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-input-synaptics 1.5.0
Only one change over the snapshot to fix up the pressure and finger width ranges. As said previously, this release doesn't bring anything big, the next version will have some interesting features though. Cheers, Peter Alexandr Shadchin (1): The correct maximum values for pressure and finger width Peter Hutterer (1): synaptics 1.5.0 git tag: xf86-input-synaptics-1.5.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.0.tar.bz2 MD5: 41ee749ecbfef98f7fba708cb2afae87 xf86-input-synaptics-1.5.0.tar.bz2 SHA1: 7373c1e3f02bf7e18f71b65762a982d907b4a053 xf86-input-synaptics-1.5.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.0.tar.gz MD5: a776801c979413c2170f084986a3a8d7 xf86-input-synaptics-1.5.0.tar.gz SHA1: 17ba02488cc1497c8d83b032fd324dca5fa1c62b xf86-input-synaptics-1.5.0.tar.gz pgpUm44Oy5VN2.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] inputproto 2.0.99.1
First snapshot of the XI 2.1 protocol specification. New features over XI 2.0: - additional defines to avoid mixing core and XI2 defines - new raw events behaviour - raw events are now sent regardless of grab state - raw events now send the sourceid down the wire - smooth scrolling support: devices may have one or more axes labelled as a scrolling valuator I should note that XI 2.1 does not include the multitouch protocol specification. That one is scheduled for XI 2.2. I'll be writing up some blog posts describing the changes in more detail, please see the following URL for more info. http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-versioning.html Please peruse the new protocol specs and let us know of any potential issues. Cheers, Peter Alexandre Julliard (1): XI2.h: Fix off-by-one error in the XIMaskLen definition. Chase Douglas (1): Include stdint.h Daniel Stone (2): Add XIPointerEmulated for emulated events Document smooth-scrolling support Fernando Carrijo (1): Fix typos in XIproto.txt Gaetan Nadon (3): specs: convert XI2proto.txt to html using asciidoc XI2proto.txt: fix whitespace issues XIproto.txt: fix whitespace issues Peter Hutterer (15): Add minimal asciidoc syntax specs: move erroneous Errors: line to where it belongs specs: enable asciidoc parsing for XIproto.txt Add XI2-specific defines for grab and property requests Provide convenience defines for owner_events. specs: add a linebreak for asciidoc parsing Put a warning in about not adding any further libXi defines specs: ValuatorClass includes a mode specs: fix two typos in XI2proto.txt Bump to 2.0.99 Announce 2.1 availability through the XI_2_Major and XI_2_Minor defines XI2.1: send RawEvents at all times. Add sourceid to RawEvents (#34420) Move scroll information into a new class. inputproto 2.0.99.1 (first snapshot of 2.1) git tag: inputproto-2.0.99.1 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.0.99.1.tar.bz2 MD5: c5a4bef0431b4197e95d1e15b2996d49 inputproto-2.0.99.1.tar.bz2 SHA1: 8688eb3f560b3f720bbcfbf74331d7317a7dc06f inputproto-2.0.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.0.99.1.tar.gz MD5: 610b6ef7ff1b48f6b5154c529e52559c inputproto-2.0.99.1.tar.gz SHA1: 8ce8200ae303348ed1bbfb7fed9a827fb722bc54 inputproto-2.0.99.1.tar.gz pgpUhDPl5GHvz.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] inputproto 2.0.99.1
First snapshot of the XI 2.1 protocol specification. New features over XI 2.0: - additional defines to avoid mixing core and XI2 defines - new raw events behaviour - raw events are now sent regardless of grab state - raw events now send the sourceid down the wire - smooth scrolling support: devices may have one or more axes labelled as a scrolling valuator I should note that XI 2.1 does not include the multitouch protocol specification. That one is scheduled for XI 2.2. I'll be writing up some blog posts describing the changes in more detail, please see the following URL for more info. http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-versioning.html Please peruse the new protocol specs and let us know of any potential issues. Cheers, Peter Alexandre Julliard (1): XI2.h: Fix off-by-one error in the XIMaskLen definition. Chase Douglas (1): Include stdint.h Daniel Stone (2): Add XIPointerEmulated for emulated events Document smooth-scrolling support Fernando Carrijo (1): Fix typos in XIproto.txt Gaetan Nadon (3): specs: convert XI2proto.txt to html using asciidoc XI2proto.txt: fix whitespace issues XIproto.txt: fix whitespace issues Peter Hutterer (15): Add minimal asciidoc syntax specs: move erroneous Errors: line to where it belongs specs: enable asciidoc parsing for XIproto.txt Add XI2-specific defines for grab and property requests Provide convenience defines for owner_events. specs: add a linebreak for asciidoc parsing Put a warning in about not adding any further libXi defines specs: ValuatorClass includes a mode specs: fix two typos in XI2proto.txt Bump to 2.0.99 Announce 2.1 availability through the XI_2_Major and XI_2_Minor defines XI2.1: send RawEvents at all times. Add sourceid to RawEvents (#34420) Move scroll information into a new class. inputproto 2.0.99.1 (first snapshot of 2.1) git tag: inputproto-2.0.99.1 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.0.99.1.tar.bz2 MD5: c5a4bef0431b4197e95d1e15b2996d49 inputproto-2.0.99.1.tar.bz2 SHA1: 8688eb3f560b3f720bbcfbf74331d7317a7dc06f inputproto-2.0.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.0.99.1.tar.gz MD5: 610b6ef7ff1b48f6b5154c529e52559c inputproto-2.0.99.1.tar.gz SHA1: 8ce8200ae303348ed1bbfb7fed9a827fb722bc54 inputproto-2.0.99.1.tar.gz pgpPGUUMekpzo.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: double-tap and hold touchpad behavior
On Tue, Aug 23, 2011 at 12:41:31AM -0500, Brandon Casey wrote: On Mon, Aug 22, 2011 at 11:42 PM, Peter Hutterer peter.hutte...@who-t.netwrote: On Mon, Aug 22, 2011 at 11:24:38PM -0500, Brandon Casey wrote: On Fri, Aug 19, 2011 at 1:15 AM, Peter Hutterer peter.hutte...@who-t.netwrote: On Wed, Aug 17, 2011 at 10:16:18PM -0500, Brandon Casey wrote: Please let me know if this is the wrong place to post this message. For a long time now I have been missing the old method that I used to use to highlight text, drag-and-drop, and move windows around. I used to be able to produce a button press-and-hold by performing a double-tap and hold (tap twice on touchpad, but leave the finger resting on the touchpad on the second tap). But with recent distributions the last few years, that doesn't work. Now, it seems, you have to double-tap, hold, and drag. Is there any way to re-enable the old double-tap-and-hold instead of the double-tap-and-drag? this probably doesn't help but I've just tried it here and it worked fine. you can disable it by unsetting the Synaptics Gestures property but it is enabled by default. So, when you double-tap-and-hold on a window title bar, without moving the mouse after the second tap (i.e. no drag gesture), your pointer grabs the title bar and the mouse icon changes to indicate that? tbh, I can't tap without moving, my touchpad is too sensible. it always moves by a few pixels at least. tbh? I don't know what that means. to be honest sensible? Did you mean sensitive? yes, sorry. ESL. I guess it's possible that your pointer moves enough after your second tap that the driver interprets it as a drag? correct. The setting is called TapAndDragGesture though, so that, along with the documentation, implies that a drag is part of the gesture. Just to make sure you understood me (and I you), when I do the above, nothing happens. It doesn't even produce an event in xev. if you're on the window bar, the event never goes to xev, it's captured by the WM. try doing it _inside_ the xev window, that should show events. Yes, sorry, when I was using xev, the pointer was within the xev window. Other operations produce the appropriate events. The dtap-and-drag gesture produces the button press and release events, intermixed with a bunch of motion events. The double-tap-and-drag gesture does work, but for that one, you have to drag your finger after the second tap (touch-release-touch-drag). The Synaptics Gestures property controls this feature. If I disable it, then it disables double-tap-and-drag, but it doesn't enable double-tap-and-hold. You then have to use the physical buttons. I can't remember any changes to this extent going into the driver. maybe it's a side-effect of other change but you'd have to look at the state machine in the driver where exactly the problem is now. My description of the behavior I am seeing is exactly what the synaptics man page describes as how the TapAndDragGesture is supposed to work. So, it seems like it is intended behavior. I just hoped the old tap-and-hold behavior could be enabled somehow. And when I say old, I mean about 5 years ago, which may predate the synaptics driver, I don't know. there's an old state diagram in docs/tapndrag.dia that claims if the timeout is hit after the second press, tap-n-drag should still take effect. so what you're seeing is likely a bug but you'd need to dig into the state machine handling in the driver to figure out where it's going wrong. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Fw: sticky xkb options ?
On Sun, Aug 21, 2011 at 06:29:32AM -0400, Marty Jack wrote: On 08/21/2011 12:44 AM, Alan Coopersmith wrote: On 08/20/11 12:45, Alan Coopersmith wrote: On 08/20/11 11:50, Matthieu Herrb wrote: And sticky xkboptions could be useful for other options too, given that a way to reset them explicitely also exist. Yes, an XkbOptionsAdd or similar to append instead of clear/set would be very nice. It would need to handle autoadding the , separator between entries, but that shouldn't be hard. Actually I guess it would be OptionAppend XkbOptions instead of Option XkbOptionsAdd, since the option parser would need to know to do the append instead of just replacing the existing value for that option. You could get into a definitional/user misunderstanding nightmare if this isn't carefully thought through. The server gets all done with startup and xorg.conf.d and later someone does a setxkbmap or if the DE does one behind your back. What happens then. Do the OptionAppends stay or disappear? we've always treated the server configuration as separate from any run-time configuration. the same would be true here, once the server finishes initialising a device, any user-space tools will simply overwrite the server. The same rule would apply here. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Fw: sticky xkb options ?
On Sat, Aug 20, 2011 at 09:44:37PM -0700, Alan Coopersmith wrote: On 08/20/11 12:45, Alan Coopersmith wrote: On 08/20/11 11:50, Matthieu Herrb wrote: And sticky xkboptions could be useful for other options too, given that a way to reset them explicitely also exist. Yes, an XkbOptionsAdd or similar to append instead of clear/set would be very nice. It would need to handle autoadding the , separator between entries, but that shouldn't be hard. Actually I guess it would be OptionAppend XkbOptions instead of Option XkbOptionsAdd, since the option parser would need to know to do the append instead of just replacing the existing value for that option. The value would have to be generic too then, not all Option settings take a comma as separator. Especially in the case of xkb variants, the effects can be quite interesting. mind you, I do wonder if a generic OptionAppend would confuse too much? there are only a few options where it makes sense, and even for other XKB settings it is a risky one to have. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: sticky xkb options ?
On 21/08/11 03:28 , Matthieu Herrb wrote: In order to keep the oldctrl+alt+backspace sequence killing X by default, I'm looking for the best place to place the configuration option. I'd like to put it in /etc/X11/xorg.conf.d/00-killserver or similar. Unfortunatly, at least with xserver 1.9 or 1.10, 'Option XkbOption terminate:ctrl_alt_bksp' doesn't stick. Any other 'Option XkbOption ...' parsed later will clear the already set options. The same is true for any initialisation done inside the xserver code itself via add_option(). Is there a way to set a sticky xkbOption ? not really, at least not without hacking the server. We use the same configuration in Fedora, but once the user is logged in, the user's settings overwrite the option as well. the solution to this is convince the user to update their configuration, sorry. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.4.99.1
First RC for synaptics 1.5. I don't want any big changes in now but let me know of any crashers that need to be fixed immediately. We've got a whole set of patches queued up for master that I don't want to merge in this cycle - especially given that 1.4 has been out for quite a while now. So here it is, the current state of synaptics that hasn't changed much for a while anyway. Many of the changes are cleanups in the driver, man pages and other changes that mostly help developers, not users. The next version (synaptics 1.6) should address more user issues. Aapo Rantalainen (1): Add synaptics orientation support Alan Coopersmith (1): Fix nose canellation typo in man page Alexandr Shadchin (11): Fix typo (resx - resy) Simplified mechanism for determining default size Renamed SynapticsDefaultDimensions in SanitizeDimensions Removing extra call SetDeviceAndProtocol() Delete empty alpscomm.h Move definition struct SynapticsHwInfo in ps2comm.h Renamed SynapticsHwInfo in PS2SynapticsHwInfo Remove arg proto_ops in ReadHwState() Remove extra definition CommData Rewrite mechanisn to detect Protocol and Device Now ps2comm and alpscomm backend optional Chase Douglas (2): Revert Default to 2-finger emulation when HW supports it Drain XRecord connection of any events after handling replies Christoph Brill (2): Add note about MatchDevicePath Update maintainer information Cyril Brulebois (1): Fix egde/edge typo in manpage and comments. Daniel Kurtz (1): conf: fix snippet to ignore /dev/input/mouse* on Linux Diego Elio Pettenò (7): build: report a fatal error if XORG_DRIVER_CHECK_EXT is undefined. build: sort building of tools, ensure that cross-pkg-config works. build: collapse all Makefile.am files into a single non-recursive one. build: install documentation as part of make install. README: fix typos. build: create object files following the sources' structure. build: apply the distcheck tricks used in xf86-input-evdev Gaetan Nadon (8): Revert build: apply the distcheck tricks used in xf86-input-evdev Revert build: create object files following the sources' structure. Revert build: install documentation as part of make install. Revert build: collapse all Makefile.am files into a single non-recursive one. Revert build: sort building of tools, ensure that cross-pkg-config works. tools: remove unrequired sdkdir include directive Add distcheck support for header files when sdk is not writable Add distcheck support for configuration files when dir is not writable Patrick Curran (1): Modified start_coasting to handle circular scrolling Peter Hutterer (40): Remove unused test directory (#35043) Revert Add synaptics orientation support Bump to 1.4.99 man: update source path for fdi file and shorten description. man: add short blurb about InputClass configuration in servers 1.8 conf: remove SHM example from fdi conf: add a descriptive header with warning to example config file eventcomm: add a missing break statement eventcomm: factor out finger counting. eventcomm: extern EventReadHwState to allow for testing. eventcomm: replace synaptics-custom TEST_BIT with server's BitIsOn. eventcomm: rename parameter name grab to test_grab eventcomm: document event_query_is_touchpad eventcomm: rewrite event_query_info to something more sane eventcomm: streamline absinfo retrieval. eventcomm: print an error when axis range failed. eventcomm: untangle state setting from printing device info eventcomm: move need_grab into a proto-specific struct. eventcomm: fix indentation in EventAutoDevProbe Don't autoprobe for devices when Option Device is set. Require macros 1.13 for unit testing Add basic framework for unit-testing. test: Add some tests for HW state changes. test: add another test to ensure HW state changes on known values only. Only build tests when unit tests are enabled. include: update documentation for capabilities property syndaemon: fix abysimal indentation in dp_get_device. syndaemon: add vim snippet for right indentation/tabstop, etc. syndaemon: don't compare against a null-property. (#37459) Use struct input_id as return value for EVIOCGID Initialize the vendor/product id property if we know either. Export device node as property. conf: add snippet to ignore /dev/input/mouse* on Linux Replace xf86Msg with xf86IDrvMsg tools: don't include xserver-properties.h man: document syndaemon -m switch man: remove documentation for -s switch, SHM is gone. syndaemon: document exit codes and change them to fall into categories. syndaemon: Remove superfluous message. Bump to 1.4.99.1
Re: double-tap and hold touchpad behavior
On Wed, Aug 17, 2011 at 10:16:18PM -0500, Brandon Casey wrote: Please let me know if this is the wrong place to post this message. For a long time now I have been missing the old method that I used to use to highlight text, drag-and-drop, and move windows around. I used to be able to produce a button press-and-hold by performing a double-tap and hold (tap twice on touchpad, but leave the finger resting on the touchpad on the second tap). But with recent distributions the last few years, that doesn't work. Now, it seems, you have to double-tap, hold, and drag. Is there any way to re-enable the old double-tap-and-hold instead of the double-tap-and-drag? this probably doesn't help but I've just tried it here and it worked fine. you can disable it by unsetting the Synaptics Gestures property but it is enabled by default. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Multiple clicks with touchscreen
On Thu, Aug 11, 2011 at 12:06:30AM -0500, Kerrick Staley wrote: Basically, what I would like to do is prevent input events from my touchscreen from appearing on /dev/input/mice. I have a dual-head setup with a regular screen (built into my laptop) on the left and a touchscreen on the right. When the touchscreen is touched, it registers two clicks; this is undesirable. From what I can find in forums, etc., the issue is that input events appear on both /dev/input/mice and /dev/input/mouse0. Indeed, when the touchscreen is touched, both devices show activity. Earlier, the multiple-click issue did not occur, but there was another issue: touchscreen events did not occur in the correct spot (they were spread across both monitors). I fixed this using $ xinput set-prop QUANTA OpticalTouchScreen --type=float Coordinate Transformation Matrix 0.5333 0 0.467 0 1 0 0 0 1 n.b. The touchscreen is a HP Compaq L2105tm, which uses a touch sensor manufactured by Quanta. The screen is 1920x1080 and is sitting to the right of the laptop, which has a 1680x1050 display, so the transformation matrix is correct. Now that the touchscreen is properly calibrated, there are two clicks: one in the correct spot, and one in the original spot (where it clicked before I invoked xinput; this location corresponds to an identity transformation matrix). How can I fix this issue? I found 3 separate solutions, none of which worked for me: 1. Disable /dev/input/mice, as described at http://www.conan.de/touchscreen/evtouch.html -There is no ServerLayout section in my xorg.conf. The dual-head layout is configured dynamically by Gnome 3 when I log in or when the monitor is attached; I'll eventually configure ivman or similar to automatically invoke xinput when the display is attached. -As I understand it, this will prevent the mouse (a TrackPoint) from working; the mouse is needed for the regular display. 2. Patch the driver, per http://www.linuxquestions.org/questions/linux-desktop-74/hal-vs-xserver-dev-input-mice-convincing-x-to-*not*-use-a-given-input-device-697802/#post3415561 -I don't know where in the driver I should insert this code; plus, the driver is part of the kernel (module hid-quanta), so I'd have to recompile my kernel. 3. Write a HAL rule, per http://www.linuxquestions.org/questions/linux-desktop-74/hal-vs-xserver-dev-input-mice-convincing-x-to-*not*-use-a-given-input-device-697802/#post3625659 -I tried this, and it didn't work. I used match key=info.product contains=OpticalTouchScreen, but I'm not sure if this is correct. I'm running X.Org 1.10.3.901 (1.10.4 RC 1) on Linux 3.0 (the distribution is Arch Linux). If there is any additional information needed (log output, etc.), please ask. I'm not sure why /dev/input/mice is even picked up, all our default rules ignore it. Do you have any rules that add it? 3ou're most likely using udev, not HAL so solution 3 won't work. the xorg.conf.d equivalent to the now-deprecated HAL solution is: https://fedoraproject.org/wiki/Input_device_configuration#Blacklisting_a_device Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Multiple clicks with touchscreen
On 11/08/11 17:31 , Kerrick Staley wrote: Peter, 3ou're most likely using udev, not HAL so solution 3 won't work. the xorg.conf.d equivalent to the now-deprecated HAL solution is: https://fedoraproject.org/wiki/Input_device_configuration#Blacklisting_a_device I tried adding these lines to /etc/X11/xorg.conf.d/20-disable-default-mouse-pointer.conf (and restarting X), but it didn't have any apparent effect: Section InputClass Identifier disable /dev/input/mice MatchDevicePath /dev/input/mice Option Ignore on EndSection I noticed that /dev/input/event12 also picks up events from the touchscreen, if this helps. Is there anything that can help identify the source of the extraneous click events? Similar to xev, except that the input device causing each event is also displayed? your Xorg.log should tell you which input classes apply for the devices in question, most likely the /dev/input/mouseX devices, not just /dev/input/mice. That input class is then at fault. Without the log file and your xorg.conf + xorg.conf.d snippets, I can't say much more than that. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Multiple clicks with touchscreen
On 11/08/11 20:33 , Kerrick Staley wrote: Here's the section of Xorg.0.log that seems relevant: you cut out some vital information, please always supply the whole log. Cheers, Peter [ 3051.308] (II) config/udev: Adding input device QUANTA OpticalTouchScreen (/dev/input/event1) [ 3051.308] (**) QUANTA OpticalTouchScreen: Applying InputClass evdev touchscreen catchall [ 3051.308] (II) Using input driver 'evdev' for 'QUANTA OpticalTouchScreen' [ 3051.308] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [ 3051.308] (**) QUANTA OpticalTouchScreen: always reports core events [ 3051.308] (**) QUANTA OpticalTouchScreen: Device: /dev/input/event1 [ 3051.308] (--) QUANTA OpticalTouchScreen: Found absolute axes [ 3051.308] (--) QUANTA OpticalTouchScreen: Found x and y absolute axes [ 3051.308] (--) QUANTA OpticalTouchScreen: Found absolute touchscreen [ 3051.308] (II) QUANTA OpticalTouchScreen: Configuring as touchscreen [ 3051.308] (**) QUANTA OpticalTouchScreen: YAxisMapping: buttons 4 and 5 [ 3051.308] (**) QUANTA OpticalTouchScreen: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [ 3051.308] (**) Option config_info udev:/sys/devices/pci:00/:00:1d.0/usb6/6-2/6-2:1.0/input/input1/event1 [ 3051.308] (II) XINPUT: Adding extended input device QUANTA OpticalTouchScreen (type: TOUCHSCREEN) [ 3051.308] (II) QUANTA OpticalTouchScreen: initialized for absolute axes. [ 3051.308] (**) QUANTA OpticalTouchScreen: (accel) keeping acceleration scheme 1 [ 3051.308] (**) QUANTA OpticalTouchScreen: (accel) acceleration profile 0 [ 3051.308] (**) QUANTA OpticalTouchScreen: (accel) acceleration factor: 2.000 [ 3051.308] (**) QUANTA OpticalTouchScreen: (accel) acceleration threshold: 4 [ 3051.308] (II) config/udev: Adding input device QUANTA OpticalTouchScreen (/dev/input/mouse0) [ 3051.308] (II) No input driver/identifier specified (ignoring) Here are all the config settings I have in /etc/X11/xorg.conf.d (there is no main xorg.conf file): $ cat 10-evdev.conf # # Catch-all evdev loader for udev-based systems # We don't simply match on any device since that also adds accelerometers # and other devices that we don't really want to use. The list below # matches everything but joysticks. Section InputClass Identifier evdev pointer catchall MatchIsPointer on MatchDevicePath /dev/input/event* Driver evdev EndSection Section InputClass Identifier evdev keyboard catchall MatchIsKeyboard on MatchDevicePath /dev/input/event* Driver evdev EndSection Section InputClass Identifier evdev touchpad catchall MatchIsTouchpad on MatchDevicePath /dev/input/event* Driver evdev EndSection Section InputClass Identifier evdev tablet catchall MatchIsTablet on MatchDevicePath /dev/input/event* Driver evdev EndSection Section InputClass Identifier evdev touchscreen catchall MatchIsTouchscreen on MatchDevicePath /dev/input/event* Driver evdev EndSection $ cat 10-quirks.conf # Collection of quirks and blacklist/whitelists for specific devices. # Accelerometer device, posts data through ABS_X/ABS_Y, making X unusable # http://bugs.freedesktop.org/show_bug.cgi?id=22442 Section InputClass Identifier ThinkPad HDAPS accelerometer blacklist MatchProduct ThinkPad HDAPS accelerometer data Option Ignore on EndSection $ cat 10-synaptics.conf Section InputClass Identifier touchpad catchall Driver synaptics MatchIsTouchpad on MatchDevicePath /dev/input/event* Option TapButton1 1 Option TapButton2 2 Option TapButton3 3 EndSection $ cat 20-disable-default-mouse-pointer.conf Section InputClass Identifier disable /dev/input/mice MatchDevicePath /dev/input/mice Option Ignore on EndSection Thanks, Kerrick ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Multiple clicks with touchscreen
On Thu, Aug 11, 2011 at 10:31:20PM -0500, Kerrick Staley wrote: On Thu, Aug 11, 2011 at 4:50 PM, Peter Hutterer peter.hutte...@who-t.net wrote: judging from that, the problem isn't in your config, it seems to be your kernel driver. evtest should show you if you get two events per click instead of one. I tried running evtest and then tapping the touchscreen both before running xinput (when the problem does not occur) and after running xinput (after which the problem does occur). The outputs were nearly identical; only the timestamps and the screen positions changed. In both cases, there are two Key events: one on tap and one on release. Here is some evtest output taken after running xinput (the issue was occurring when this output was taken): oh, crud. Now I realise what's going on. Pretty sure you experience http://patchwork.freedesktop.org/patch/5024/ Jeremy, can you pick this up for 1.10 please? we ship it in Fedora, upstream fixed it differently (but not as easy to backport). I just forgot to nominate it for you. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Multiple clicks with touchscreen
On Thu, Aug 11, 2011 at 09:30:04PM -0700, Jeremy Huddleston wrote: Just to confirm, this is what you want, right: correct. thanks. Cheers, Peter From 8b0e57a508c70923bd0b1c03f28026b6bbb03f44 From: Peter Hutterer peter.hutte...@who-t.net Date: Thu, 21 Apr 2011 17:35:55 +1000 Subject: [PATCH] dix: only transform valuators when we need them. Unconditionally drop the valuators back into the mask when they were there in the first place. Otherwise, sending identical coordinates from the driver on a translated device causes the valuator mask to be alternatively overwritten with the translated value or left as-is. This leads to the device jumping around between the translated and the original position. The same could be achieved with a valuator_mask_unset() combination. Testcase: xsetwacom set device name MapToOutput VGA1 Then press a button on the device, cursor jumps between the two positions. Introduced in 31737fff08ec19b394837341d5e358ec401f5cd8 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net Reviewed-by: Daniel Stone dan...@fooishbar.org Reviewed-by: Chase Douglas chase.doug...@canonical.com --- dix/getevents.c | 57 +- 1 files changed, 55 insertions(+), 2 deletions(-) diff --git a/dix/getevents.c b/dix/getevents.c index 0fa8046..7afd330 100644 --- a/dix/getevents.c +++ b/dix/getevents.c @@ -1065,9 +1065,10 @@ transformAbsolute(DeviceIntPtr dev, ValuatorMask *mask) pixman_f_transform_point(dev-transform, p); -if (lround(p.v[0]) != dev-last.valuators[0]) +if (valuator_mask_isset(mask, 0)) valuator_mask_set(mask, 0, lround(p.v[0])); -if (lround(p.v[1]) != dev-last.valuators[1]) + +if (valuator_mask_isset(mask, 1)) valuator_mask_set(mask, 1, lround(p.v[1])); } ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XGrabKey: Passive grabs on a key by multiple clients
On Sun, Aug 07, 2011 at 10:45:03PM -0400, edmund brown wrote:
Greetings!
I am using the following basic code in a client to grab and act on
a single specific hotkey:
/* Only one key is grabbed by the client (no other XGrabKey() call) */
XGrabKey(dpy, hotkeycode, 0,
DefaultRootWindow(dpy), True, GrabModeAsync, GrabModeAsync);
for(i=0; i MAX_HITS; i++) { /* Main event loop */
XNextEvent(dpy, ev);
if (ev.type == KeyPress || ev.type == KeyRelease) {
/*
* Got an active grab on the hotkey at this point, but this
* active grab is auto-terminated at key release (RTFM).
*/
printf(Key event %d: keycode=%d\n, i, ev.xkey.keycode);
}
}
When this client is started but the hotkey has not been pressed yet,
the execution blocks at the XNextEvent() call in the very first pass
through the loop (i==0). If a second instance of the client is now
started (with no occurrence of the hotkey still), its XGrabKey() call
returns a BadAccess error, which is what I had expected.
Now suppose that we hit the hotkey a few times (with the first client
as the only one running), so that the loop is traversed a few times.
(The client keeps receiving the hotkey hits globally, irrespective of
focus, so the hotkey seems to remain in a passive grab by the client.)
We then stop hitting the hotkey, so that execution again blocks at the
XNextEvent() call in the loop, but with i 0. But now if a second
instance of the client is again started, its XGrabKey() call (on the
same hotkey) does not see the BadAccess error any more! In fact,
the second client this time is able to successfully install a passive
grab on the hotkey, _overriding_ the first client's grab, and all
subsequent hotkey presses go to the second client, irrespective
of focus. (If the second client is terminated, the first client's
passive grab seems to be restored, as subsequent presses of the
hotkey are sent to the first client again.)
Note that all this happens irrespective of focus target.
Q: I am fairly new to Xlib programming and find it puzzling that
other clients are able to override passive grabs on a key by
previously running clients. Is this a feature?
it's a bug, see
https://bugs.freedesktop.org/show_bug.cgi?id=39545
Cheers,
Peter
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Emulate3Buttons not honored
On Wed, Jul 27, 2011 at 09:28:52AM -0400, K Vanw wrote: On Tue, Jul 26, 2011 at 6:13 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Tue, Jul 26, 2011 at 05:48:12PM -0400, K Vanw wrote: On Mon, Jul 25, 2011 at 11:03 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Mon, Jul 25, 2011 at 09:41:34PM -0400, K Vanw wrote: [...] As you can see, the Middle Button Emulation is not set. but xinput set-prop 10 270 1 will set it correctly. So how do I get this set via an xorg.conf.d file? try starting a plain X server without a desktop environment. does it work then? Interesting. I was using the Gnome wm, but switched to good old fluxbox and it worked fine (also works without a wm as Peter suggested). That is, it correctly set Emulate3Buttons from my xorg.conf.d file. So the question is, why/how is gnome turning it off? Not really an X11 question, but maybe someone here knows. gsettings set org.gnome.settings-daemon.peripherals.mouse middle-button-enabled true should get you there, it's probably false now (it is on my machine and I don't think I ever set this myself) Yep. Thanks. BTW, do you know how to set an inertia value for my pointer so when I flick the touchpad the pointer will coast ala a trackball? I have this on my laptop and find it useful. Coasting should be enabled by default with synaptics 1.3 and later. Options CoastingSpeed and CoastingFriction are the triggers, just look up the synaptics man page, that should explain it. That's just for scrolling though, we don't have any coasting implementation for the pointer movement. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: button presses dont show up in xev
On Sat, May 14, 2011 at 01:48:19PM +0200, Johannes Schauer wrote: hi all, I am running Debian unstable on the Notion Ink Adam tablet. The device is having four buttons that show up as /dev/input/event1. /dev/input/event1 will also produce output when the buttons are pressed. The raw output of pressing all four buttons one after each other can be seen here: http://mister-muffin.de/p/pJo2.txt evtest produces this output when pressing all four buttons one after another: http://mister-muffin.de/p/YoYL.txt looks like your kernel driver is busted. evdev doesn't actually process events until it sees an EV_SYN, it queues them up internally. You should be seeing these lines in the evtest log: Event: time 1311718017.941980, -- Report Sync They're missing, so I can only assume that the kernenl driver doesn't do the right thing here. If you put xf86Msg() statements into xf86-input-evdev/src/evdev.c:EvdevQueueKbdEvent, you'll probably see them show up there (but not in EvdevPostQueuedEvents). Cheers, Peter I started xorg with startx /usr/bin/xterm and then started xev but in contrast to touchscreen events or events from the attached usb keyboard, there is no output when pressing one of those four buttons. This is my /var/log/Xorg.0.log: http://mister-muffin.de/p/j6lq.txt And here is my /proc/bus/input/devices: http://mister-muffin.de/p/PjEq.txt How can I find out what is wrong and why I get output on /dev/input/event1 and with evtest but nothing with xev? cheers, josch ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Emulate3Buttons not honored
On Tue, Jul 26, 2011 at 05:48:12PM -0400, K Vanw wrote: On Mon, Jul 25, 2011 at 11:03 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Mon, Jul 25, 2011 at 09:41:34PM -0400, K Vanw wrote: [...] As you can see, the Middle Button Emulation is not set. but xinput set-prop 10 270 1 will set it correctly. So how do I get this set via an xorg.conf.d file? try starting a plain X server without a desktop environment. does it work then? Interesting. I was using the Gnome wm, but switched to good old fluxbox and it worked fine (also works without a wm as Peter suggested). That is, it correctly set Emulate3Buttons from my xorg.conf.d file. So the question is, why/how is gnome turning it off? Not really an X11 question, but maybe someone here knows. gsettings set org.gnome.settings-daemon.peripherals.mouse middle-button-enabled true should get you there, it's probably false now (it is on my machine and I don't think I ever set this myself) Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Emulate3Buttons not honored
On Mon, Jul 25, 2011 at 03:34:37PM -0700, walt wrote: On 07/25/2011 07:27 AM, Kevin Van Workum wrote: ... I'm trying to get my ORtek Wireless Touchpad keyboard to emulate 3 buttons... ... Note that X reports that it 'Found 3 mouse buttons', but in fact there are only 2 real buttons... Sounds like you already know more about this stuff than I do :) Just an idle observation: I have a four-button trackball mouse that xorg announces as having 9 buttons. According to xev, the buttons are 1: Left click 3: Right click 2: buttons 1 and 3 pressed at the same time 8: Left tiny-button click 9: Right tiny-button click That's all. Buttons 4-7 don't exist. Someone in this mailing list explained this numbering system to me a long time ago. Shame I can't remember it now :( 4-7 are the four scroll directions, so any physical button 4+ gets mapped to logical button 8+. see also http://who-t.blogspot.com/2009/06/button-mapping-in-x.html Cheers, Peter Anyway, my point is that button numbering schemes can be sneaky, and you may learn something interesting if you run xev and click the buttons in random ways, maybe including double-tapping the touchpad, etc. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: evdev fails with Couldn't open mtdev device
On Tue, Jul 12, 2011 at 01:48:53PM +0200, Florian Echtler wrote: On Mon, 2011-07-11 at 16:07 -0700, walt wrote: Have you read about the new InputClass Section? It has some advantages over the older InputDevice, including the important ability to identify devices by their plug-n-play names instead the event number. As an example, here's my input section for a non-standard mouse: #cat /etc/X11/xorg.conf.d/10-trackball.conf Section InputClass --- note the new name Identifier trackball - I made this name up MatchProduct ImExPS- important: I did not make this up Option AutoServerLayout on Option Emulate3Buttons on Option EmulateWheel on Option EmulateWheelButton 8 EndSection Thanks for the hint - I've also stumbled across that in the manpage and it actually does provide sort of a solution for my problem: Section InputDevice Identifier nullpointer Driver void Option CorePointer true EndSection Section InputClass Identifier mimoTouch MatchIsTouchscreen true Option InvertY true Option Calibration 1252 31534 1598 31680 EndSection Section InputClass Identifier nokeyboard MatchIsKeyboard true Option Ignore true EndSection Section InputClass Identifier nomouse MatchIsPointer true Option Ignore true EndSection Section ServerFlags Option AllowEmptyInput true Option AutoAddDevices true Option AutoEnableDevices false EndSection So I have 3 InputClasses - 2 to disable standard devices, 1 to configure the touchscreen and one void InputDevice to disable the default core pointer (which would otherwise use /dev/input/mice). Looks a bit like a hack to me, but works. input classes accumulate in lexical sort order (for the filenames). So you could have a class that ignores _all_ input devices and then set Option Ignore false for the ones you want to enable. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: evdev fails with Couldn't open mtdev device
On Mon, Jul 11, 2011 at 11:24:28AM +0200, Florian Echtler wrote: Hi everyone, I'm trying to configure a secondary X server for an auxiliary touchscreen, but I'm having some problems with the input configuration. To keep input for my main screen and the auxiliary screen separate, I'm using the following config for the secondary one: Section InputDevice Identifier mimoTouch Driver evdev Option CorePointer trueB CorePointer is a default anyway, so yuou don't need it (besides, deprecated upstream, see Option Floating) Option Device /dev/input/event2 EndSection Section ServerFlags Option AllowEmptyInput true don't ever use this option. We've even removed it upstream now so people can't use it anymore but I don't know if your server version carries the patch. Option AutoAddDevices false Option AutoEnableDevices false EndSection The idea is that the secondary server doesn't touch any devices from the primary, just the statically configured touchscreen device. However, I'm getting the following error (the touchscreen is single-touch): (II) Using input driver 'evdev' for 'mimoTouch' (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so (**) Option CorePointer (**) mimoTouch: always reports core events (**) mimoTouch: Device: /dev/input/event2 (EE) mimoTouch: Couldn't open mtdev device (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device (EE) PreInit returned 8 for mimoTouch (II) Unloading evdev for the mtdev stuff, not sure. We don't carry that upstream yet and I'm not sure what Ubuntu ships here. However, I do notice that your config says event2 and your log snippet says event8. This may be the source for the issue. Cheers, Peter On the other hand, when I set AutoAddDevices to true, then evdev handles the touchscreen just fine: (II) config/udev: Adding input device e2i Technology, Inc. USB Touchpanel (/dev/input/event8) (**) e2i Technology, Inc. USB Touchpanel: Applying InputClass evdev touchscreen catchall (II) Using input driver 'evdev' for 'e2i Technology, Inc. USB Touchpanel' (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so (**) e2i Technology, Inc. USB Touchpanel: always reports core events (**) e2i Technology, Inc. USB Touchpanel: Device: /dev/input/event8 (--) e2i Technology, Inc. USB Touchpanel: Found absolute axes (II) evdev-grail: failed to open grail, no gesture support (--) e2i Technology, Inc. USB Touchpanel: Found x and y absolute axes (--) e2i Technology, Inc. USB Touchpanel: Found absolute touchscreen (II) e2i Technology, Inc. USB Touchpanel: Configuring as touchscreen (**) e2i Technology, Inc. USB Touchpanel: YAxisMapping: buttons 4 and 5 (**) e2i Technology, Inc. USB Touchpanel: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (**) Option config_info udev:/sys/devices/pci:00/:00:1d.7/usb2/2-2/2-2.3/2-2.3:1.0/input/input31/event8 (II) XINPUT: Adding extended input device e2i Technology, Inc. USB Touchpanel (type: TOUCHSCREEN) (II) e2i Technology, Inc. USB Touchpanel: initialized for absolute axes. (**) e2i Technology, Inc. USB Touchpanel: (accel) keeping acceleration scheme 1 (**) e2i Technology, Inc. USB Touchpanel: (accel) acceleration profile 0 (**) e2i Technology, Inc. USB Touchpanel: (accel) acceleration factor: 2.000 (**) e2i Technology, Inc. USB Touchpanel: (accel) acceleration threshold: 4 So my question is: what do I have to do to get the static config to work just like the auto-added config? OS is stock Ubuntu 11.04. Thanks, Florian ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Configuration of MPX - xorg.conf sample?
On Mon, Jul 04, 2011 at 02:56:29AM +0300, Igor 'Lo' (И.L.) wrote: Can anyone share a piece of working multi-pointer configuration which will let me see and manage input devices with xinput? Using a plain InputDevice (kdb, mouse) sections, need help with switching to Xinput2. http://live.gnome.org/Metacity/MpxHowto and some other manuals are having dead links to xorg.conf, thus no useful example. Please CC me when answering. you don't need an xorg.conf. Provided you have multiple input devices (which you will have in the default configuration), you can just reassign them to new pointers on-the-fly. xinput list (for the list of devices) xinput create-master some name # new pair of master devices xinput reattach my mouse some name pointer xinput reattach my keyboard some name keyboard with the names replaced with your device names of course. There is no static configuration in the xorg.conf available for this, it's run-time only. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-hyperpen 1.4.1
This driver is one of the legacy input drivers that you almost certainly don't want to use. Use the kernel driver instead (if one exists) or write one (if none exists). Mind you, I noticed we actually have (had?) a user for this driver, Manuel is on CC now. One bugfix for a crasher on startup. Regression introduced with 1.4.0, a missing type_name caused a strdup(NULL). Peter Hutterer (3): Fill in missing type_name. Remove some if 0 code now obsolete hyperpen 1.4.1 git tag: xf86-input-hyperpen-1.4.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-hyperpen-1.4.1.tar.bz2 MD5: 75dc36477a291f8c2f7c808ab78a400a xf86-input-hyperpen-1.4.1.tar.bz2 SHA1: 4a3555310e812dc895b7493b11f7377314c36a75 xf86-input-hyperpen-1.4.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-hyperpen-1.4.1.tar.gz MD5: 2024a81e10f603a45de7645be64df374 xf86-input-hyperpen-1.4.1.tar.gz SHA1: d5ef75414a68d672e9c8bd70d62ab40ab70aae2f xf86-input-hyperpen-1.4.1.tar.gz pgp76MnWurDBB.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Evdev problem with keyboard
On Sat, Jul 02, 2011 at 12:17:27PM +0100, Scott Waye wrote: On 27/06/2011 02:54, Markus Strobl wrote: On 06/26/2011 05:58 PM, Peter Hutterer wrote: On Sat, Jun 25, 2011 at 06:56:14PM +0100, Scott Waye wrote: I have a bluetooth Logitech diNovo Edge keyboard (with mouse pad) which I'm trying to get working using the evdev driver. I believe the bluetooth part is working fine as I get two devices in /dev/input . Not sure if this will be much help, but I do have that same keyboard working fine on a kubuntu box. Reason I say I may not be much help is because I didn't have to do anything to get it to work. I just had to pair the bluetooth devices and then it worked (both keyboard and mouse pad). I do know the dongle can operate in two modes, HID and HCI. Do you know which mode yours is in? Maybe you could run a live cd of (k)ubuntu with your keyboard and see what they did as far as config files? Thanks for all the suggestions. In the end I just removed the XkbModel and it worked. Peter's comment about it just working for him encouraged me to try to simplify things. I also put back the device path to event* in case the event number changes on reboot. I must admit that I don't understand how it maps the bytes sequences coming from the keyboard into characters, but I guess there is a udev rule somewhere which is doing this. it's a kernel-specific protocol that consists of struct input_event. Just look at linux/input.h, it provides all the magic numbers. Section InputClass Identifier evdev keyboard catchall MatchIsKeyboard on MatchDevicePath /dev/input/event* Driver evdev Option SendCoreEvents True #Option XkbLayout uk #Option XkbModel evdev EndSection SendCoreEvents is enabled by default anyway. This section should have no effect, as it should be provided by your distro (check /usr/share/X11/xorg.conf.d/10-evdev.conf). So chances are you can remove it. If you still want the layout to be uk (in case your DE doesn't set it), just leave this section with only Identifier, MatchIsKeyboard and XkbLayout. Cheers, Peter Regards the HID/HCI modes I noticed this recent thread (http://help.lockergnome.com/linux/Bug-626975-bluez-Logitech-diNovo-Edge-Keyboard-working--ftopict537340.html) which suggests that things are not quite right with way this keyboard is currently set up. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-aiptek 1.4.1
This is a stable release to the aiptek driver, one of the legacy drivers. For shutting down the driver, the previous release(s) relied on heap memory values staying the same after a free(3) call. If such optimism is inappropriate on your system, you're encouraged to update to this release. Peter Hutterer (6): Don't call DEVICE_OFF in UnInit. Only free the device-common if we actually have a device. Don't pretend successfully opening the device is an error. Don't rely on freed memory to keep values. Remove references to other devices after shutdown. aiptek 1.4.1 git tag: xf86-input-aiptek-1.4.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-aiptek-1.4.1.tar.bz2 MD5: 8231f6ce1c477eac653c9deb527fa3cb xf86-input-aiptek-1.4.1.tar.bz2 SHA1: 55ea7d12d3e24fd72eacc966a59262864dce7769 xf86-input-aiptek-1.4.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-aiptek-1.4.1.tar.gz MD5: 6d81a2a44d9ed457229c8250c7f61ff8 xf86-input-aiptek-1.4.1.tar.gz SHA1: 986800092dff30cd5707be368ea2301adf085cb1 xf86-input-aiptek-1.4.1.tar.gz pgp2pxbNn2nEI.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
On Tue, Jun 28, 2011 at 11:02:19AM +0100, Alan Cox wrote: the standard is pretty much defined by what the driver can take. If it can't parse the protocol then the device is rather useless anyway. but really, writing a serial kernel driver is rather trivial and has a higher chance of actually working long-term than dragging the old input drivers along. Except that you need to write a lot of input drivers - for Linux, for OpenBSD, for NetBSD, for Dragonfly etc.. In the Linux case yes you could write an fpit to Linux input layer ldisc but that only fixes the world for a single OS. I think Piotr's email was the first time in years that I even heard of someone using this driver. I suspect the number of BSD users of this driver is rather limited but if there's loads of them I'm sure they could step forward and help with testing. Cheers, Peter Re; polling - a lot of these fpit devices have weird IRQs for the serial, you may find they are not in fact polled but need a suitable IRQ forcing. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-aiptek 1.4.1
This is a stable release to the aiptek driver, one of the legacy drivers. For shutting down the driver, the previous release(s) relied on heap memory values staying the same after a free(3) call. If such optimism is inappropriate on your system, you're encouraged to update to this release. Peter Hutterer (6): Don't call DEVICE_OFF in UnInit. Only free the device-common if we actually have a device. Don't pretend successfully opening the device is an error. Don't rely on freed memory to keep values. Remove references to other devices after shutdown. aiptek 1.4.1 git tag: xf86-input-aiptek-1.4.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-aiptek-1.4.1.tar.bz2 MD5: 8231f6ce1c477eac653c9deb527fa3cb xf86-input-aiptek-1.4.1.tar.bz2 SHA1: 55ea7d12d3e24fd72eacc966a59262864dce7769 xf86-input-aiptek-1.4.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-aiptek-1.4.1.tar.gz MD5: 6d81a2a44d9ed457229c8250c7f61ff8 xf86-input-aiptek-1.4.1.tar.gz SHA1: 986800092dff30cd5707be368ea2301adf085cb1 xf86-input-aiptek-1.4.1.tar.gz pgphyHjv4Id7Q.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.4.1
The first stable update to synaptics 1.4 is now available. Sorry about the delay, the RC was out for over 2 months, definitely longer than planned. Only a few documentation changes over the RC and one fix in the property code. Users of 1.4.0 are recommended to update. Alan Coopersmith (1): Fix nose canellation typo in man page Christoph Brill (1): Update maintainer information Diego Elio Pettenò (1): README: fix typos. Peter Hutterer (4): include: update documentation for capabilities property syndaemon: fix abysimal indentation in dp_get_device. syndaemon: don't compare against a null-property. (#37459) synaptics 1.4.1 git tag: xf86-input-synaptics-1.4.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.4.1.tar.bz2 MD5: 2dac10f93918ed5bf7d1039d56880cf4 xf86-input-synaptics-1.4.1.tar.bz2 SHA1: e41201476f4bc8658291808d2d6ef2e0535179ae xf86-input-synaptics-1.4.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.4.1.tar.gz MD5: 5c677b11cec37e792234753996f969db xf86-input-synaptics-1.4.1.tar.gz SHA1: 09fdf7432e4aa68dc488ce3336d7dc85e954 xf86-input-synaptics-1.4.1.tar.gz pgpXsPUqvLUvg.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
On Mon, Jun 27, 2011 at 10:48:55PM +0200, Piotr Gluszenia Slawinski wrote: Thanx for maintaining the driver. AFAIK kernel input driver does not exist, and this is one of last resort to make one enjoy wonders of X. ad. testing - i still use much older version , which works fine, except pointer goes crazy under heavy load sometimes. it seems that it's serial port is polled, and machines have issues with acpi timer sources, which in combination makes bit of disaster. either way it's useable on fujitsu stylistic 2300 i happen to own. btw. recently i've thought of standarising such old devices by hardware hacking , i.e. to insert 'standariser' device inbetween computer and problem device like some once-released-never-maintained tablet, mouse, etc. such device would be simple transcoding microcontroller. ofc. for devices like tablets or laptops this is still not really applicable, as it's difficult to hack something like this inside... one of problems with such thing though is that there are not really 'standard' devices , i.e. each of them is related to some vendor , and any of them is not de facto 'standard'. the standard is pretty much defined by what the driver can take. If it can't parse the protocol then the device is rather useless anyway. but really, writing a serial kernel driver is rather trivial and has a higher chance of actually working long-term than dragging the old input drivers along. Cheers, Peter On Mon, 27 Jun 2011, Peter Hutterer wrote: This driver is one of the legacy input drivers that you almost certainly don't want to use. Use the kernel driver instead (if one exists) or write one (if none exists). This release brings the usual input ABI updates, cleanups, etc. and one real bugfix. 1.4.0 has actually seen testing in the form of loading the module, enjoying a view of a non-crashing X server (-retro too, I'm soo 80s today...) and thus deducting that the driver is bug-free. Which is more testing than previous releases have seen. Nonetheless, you may not want to control your nuclear power plants with this driver. Alan Coopersmith (1): Fill in COPYING file, add SubmittingPatches URL to README Peter Hutterer (19): Cope with XINPUT ABI 7. Fix module unloading. Remove unused bits from configure.ac Bump to 1.3.99 Purge CVS tags Remove refcount field, dropped from the server unifdef XFree86LOADER Replace LocalDevicePtr with InputInfoPtr. Drop close_proc, conversion_proc, reverse_conversion_proc Drop libc wrappers for free, malloc Require server 1.9, drop earlier ABI support Use GetMotionHistorySize() instead of driver-internal history Support input ABI 12 Bump minimum required server version to 1.10 Include xorg-server.h, not xorgVersion.h Reshuffle configure.ac to be more in-line with other modules Remove usage of sdkdir - not used by this driver Add 50-fpit.conf default configuration file. fpit 1.4.0 philip (1): fpit: minX/ maxX get wrongly initialized git tag: xf86-input-fpit-1.4.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-fpit-1.4.0.tar.bz2 MD5: 042c95fec145d8b57ca62714131ff3f1 xf86-input-fpit-1.4.0.tar.bz2 SHA1: 9305d30ae22d37c6b5bb975adc8ecda9b1d6c5e6 xf86-input-fpit-1.4.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-fpit-1.4.0.tar.gz MD5: 1f262074106c855b090295faadaedb80 xf86-input-fpit-1.4.0.tar.gz SHA1: 58c3b2f8306e5f2fa69a7636e2d74a88ca24e703 xf86-input-fpit-1.4.0.tar.gz ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
On Tue, Jun 28, 2011 at 01:03:32AM +0200, Piotr Gluszenia Slawinski wrote: the standard is pretty much defined by what the driver can take. If it can't parse the protocol then the device is rather useless anyway. but really, writing a serial kernel driver is rather trivial and has a higher chance of actually working long-term than dragging the old input drivers along. as long as it'll be maintained, well written, and pulled into mainline at all ;) now i also realized that as fpit driver uses just serial port, it could be perhaps just translated in software , and simple userspace translator similiar to how ppl used joysticks in thinkpads (i recall it was sth like gpm relay) could be used . this way relatively simple code would be created requiring no periodic mainteance, interfacing with more 'standard' X input driver. once it's in the kernel, the kernel driver will fulfill exactly those requirements... imo software that doesn't require maintainance is a pipe-dream though. Cheers, Peter then one of obstacles here is that fpit has no gpm driver ;) but it's just general idea for possibly making such devices least mainteance-labour consuming in future and not requirin destabilising whole system by introducing third party kernel drivers written by lazy and unqualified ppl ;) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-mutouch 1.3.0
This driver is one of the legacy input drivers that you almost certainly don't want to use. Use the kernel driver instead (if one exists) or write one (if none exists). This release brings the usual input ABI updates, cleanups, etc. And one bugfix. Woo! Alan Coopersmith (2): Remove xorgconfig xorgcfg from See Also list in man page Add README with pointers to mailing list, bugzilla git repos Fernando Vicente (1): Fix calculation of coordinates with inverted axes Julien Cristau (1): Don't clobber CFLAGS Peter Hutterer (20): Cope with XINPUT ABI 7. Bump to 1.2.99 Purge CVS tags unifdef XFree86LOADER Drop ref count, removed from server. Drop unused bits from configure.ac Require server 1.9, drop earlier ABI support Replace LocalDevicePtr with InputInfoPtr. Drop libc wrappers for free, malloc Drop close_proc, conversion_proc, reverse_conversion_proc Drop driver-specific motion history size handling. Replace use of private_flags with driver-internal device_type. Support input ABI 12 s/MicroTouch/MuTouch Require server 1.10 instead of manual ABI checks. Don't free pInfo on PreInit failure. Don't call DEVICE_OFF during Uninit Don't free pInfo in Uninit. Don't reset the stored device's private mutouch 1.3.0 git tag: xf86-input-mutouch-1.3.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-mutouch-1.3.0.tar.bz2 MD5: d84374b3eecc2d7156f5b694e79f66ac xf86-input-mutouch-1.3.0.tar.bz2 SHA1: 55702932f9ecef29bf9b096b9fdc45aa45614db5 xf86-input-mutouch-1.3.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-mutouch-1.3.0.tar.gz MD5: 82404ceaad02458ff56143b1d558802c xf86-input-mutouch-1.3.0.tar.gz SHA1: 391afe2df2fcd1ce0657094261baca0493bba8d3 xf86-input-mutouch-1.3.0.tar.gz pgpByXUj9ehJ7.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
On Tue, Jun 28, 2011 at 01:47:43AM +0200, Piotr Gluszenia Slawinski wrote: I believe the point is to have such a driver in the vanilla kernel, not to adopt a third-party driver. Is this hardware available anywhere besides thrift stores? personally i doubt it, thus i doubt it makes any point to try to put it to vanilla. also there are other devices like tablets (like the wacom stuff), joysticks, touchpads etc. which are cursed with similiar problem - they appear as 'mere' serial device, they 'just' stream the data, yet each of them speaks bit different language. and then - they all seem to do quite same thing... xyz/buttons... ...except perhaps some 'universal' driver could be created, which would have option to transcode inbetween various input devices like those internally... so 'desperate users' could just tinker with translation rules , rather than having to modify driver itself (even though it might seem so simple...) yeah, that is exactly what the evdev kernel interface is for :) Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.4.1
The first stable update to synaptics 1.4 is now available. Sorry about the delay, the RC was out for over 2 months, definitely longer than planned. Only a few documentation changes over the RC and one fix in the property code. Users of 1.4.0 are recommended to update. Alan Coopersmith (1): Fix nose canellation typo in man page Christoph Brill (1): Update maintainer information Diego Elio Pettenò (1): README: fix typos. Peter Hutterer (4): include: update documentation for capabilities property syndaemon: fix abysimal indentation in dp_get_device. syndaemon: don't compare against a null-property. (#37459) synaptics 1.4.1 git tag: xf86-input-synaptics-1.4.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.4.1.tar.bz2 MD5: 2dac10f93918ed5bf7d1039d56880cf4 xf86-input-synaptics-1.4.1.tar.bz2 SHA1: e41201476f4bc8658291808d2d6ef2e0535179ae xf86-input-synaptics-1.4.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.4.1.tar.gz MD5: 5c677b11cec37e792234753996f969db xf86-input-synaptics-1.4.1.tar.gz SHA1: 09fdf7432e4aa68dc488ce3336d7dc85e954 xf86-input-synaptics-1.4.1.tar.gz pgpw5c94LcMxs.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-elographics 1.3.0
This driver is one of the legacy input drivers that you almost certainly don't want to use. Use the kernel driver instead (if one exists) or write one (if none exists). This release brings the usual input ABI updates, cleanups, etc. and one real bugfix. This release requires server 1.10 for the input ABI updates. 1.3.0 loads and complains that I don't have any elographics devices. Which is correct, hence the driver is clearly working correctly. Peter Hutterer (10): Bump to 1.2.99 unifdef XFree86LOADER Replace LocalDevicePtr with InputInfoPtr Require server 1.9, drop earlier ABI support Drop driver-specific motion history size handling. Drop close_proc, conversion_proc, reverse_conversion_proc Remove refcount field, dropped from the server Support input ABI 12 Require server 1.10 elographics 1.3.0 git tag: xf86-input-elographics-1.3.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-elographics-1.3.0.tar.bz2 MD5: 9c6616048cd589d6e8540c1d397f64ab xf86-input-elographics-1.3.0.tar.bz2 SHA1: 1f8480019607e0e366eb5ce4a3f3278fc164d7f7 xf86-input-elographics-1.3.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-elographics-1.3.0.tar.gz MD5: 389394af811d65241c17da7544fa4aaf xf86-input-elographics-1.3.0.tar.gz SHA1: 4b49781181d4e07507c3caf3fb4dd431c977a0cb xf86-input-elographics-1.3.0.tar.gz pgpDVOJAbky72.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: Evdev problem with keyboard
On Sat, Jun 25, 2011 at 06:56:14PM +0100, Scott Waye wrote: I have a bluetooth Logitech diNovo Edge keyboard (with mouse pad) which I'm trying to get working using the evdev driver. I believe the bluetooth part is working fine as I get two devices in /dev/input . If I cat /dev/input/event5 I get a stream of characters when I press keys, and when I cat /dev/input/event6 I get a stream of characters when I move the mouse. I have the following in /etc/X11/xorg.conf.d/10-evdev.conf Section InputClass Identifier evdev pointer catchall MatchIsPointer on MatchDevicePath /dev/input/event6 Driver evdev Option Calibration 230 900 70 718 EndSection Section InputClass Identifier evdev keyboard catchall MatchIsKeyboard on MatchDevicePath /dev/input/event5 Driver evdev Option XkbLayout uk Option XkbModel logidinovoedge EndSection InputClass sections can apply to more than one device and the actual device path doesn't matter. In your case, you restrict matching to a single device and lose the benefit of input classes. The device path isn't guaranteed to stay fixed either, so you may after a reboot loose your keyboard if the number changes. MatchIsKeyboard already matches on keyboards only, just modify both MatchDevicePath to use /dev/input/event* (not a specific number) and you're probably fine. Cheers, Peter With this setup the mouse works fine, but the keyboard does almost nothing. I say almost because with the I bar cursor in an xterm, when a key is pressed the cursor disappears immediately as though it has detected the keypress, but no characters appear on the screen. I've tried to run xev, but I can't get it to display anything except a square. I should point out that I'm not running a window manager and I run the xterm (and xev) direct from my .xinitrc. There are no /etc/X11/*.conf files, only the xorg.conf.d directory which contains the 10-evdev.conf above and a 10-quirks.conf (one entry to do with ThinkPad) and 20-nvidia.conf. This is an ArchLinux system and my complete Xorg log follows at the end. [1210146.304] X.Org X Server 1.9.2 Release Date: 2010-10-30 [1210146.304] X Protocol Version 11, Revision 0 [1210146.304] Build Operating System: Linux 2.6.35-ARCH x86_64 [1210146.304] Current Operating System: Linux giradot 2.6.36-ARCH #1 SMP PREEMPT Sat Jan 8 14:15:27 CET 2011 x86_64 [1210146.304] Kernel command line: root=/dev/sda1 ro [1210146.304] Build Date: 01 November 2010 10:29:19PM [1210146.304] [1210146.304] Current version of pixman: 0.20.0 [1210146.304] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [1210146.304] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [1210146.304] (==) Log file: /var/log/Xorg.0.log, Time: Sat Jun 25 18:47:53 2011 [1210146.305] (==) Using config directory: /etc/X11/xorg.conf.d [1210146.305] (==) No Layout section. Using the first Screen section. [1210146.305] (==) No screen section available. Using defaults. [1210146.305] (**) |--Screen Default Screen Section (0) [1210146.305] (**) | |--Monitor default monitor [1210146.305] (==) No device specified for screen Default Screen Section. Using the first device section listed. [1210146.305] (**) | |--Device Default nvidia Device [1210146.305] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [1210146.305] (==) Automatically adding devices [1210146.305] (==) Automatically enabling devices [1210146.305] (WW) The directory /usr/share/fonts/OTF/ does not exist. [1210146.305] Entry deleted from font path. [1210146.305] (WW) The directory /usr/share/fonts/Type1/ does not exist. [1210146.305] Entry deleted from font path. [1210146.305] (==) FontPath set to: /usr/share/fonts/misc/, /usr/share/fonts/TTF/, /usr/share/fonts/100dpi/, /usr/share/fonts/75dpi/ [1210146.305] (==) ModulePath set to /usr/lib/xorg/modules [1210146.305] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [1210146.305] (II) Loader magic: 0x7d3360 [1210146.305] (II) Module ABI versions: [1210146.305] X.Org ANSI C Emulation: 0.4 [1210146.305] X.Org Video Driver: 8.0 [1210146.305] X.Org XInput driver : 11.0 [1210146.305] X.Org Server Extension : 4.0 [1210146.306] (--) PCI:*(0:0:18:0) 10de:053b:1043:82b3 rev 162, Mem @ 0xda00/16777216, 0xc000/268435456, 0xd900/16777216, BIOS @ 0x/131072 [1210146.306] (--) PCI: (0:1:6:0) 14f1:8800:0070:6906 rev 5, Mem @ 0xdf00/16777216 [1210146.306] (WW) Open ACPI failed
[ANNOUNCE] xf86-input-fpit 1.4.0
This driver is one of the legacy input drivers that you almost certainly don't want to use. Use the kernel driver instead (if one exists) or write one (if none exists). This release brings the usual input ABI updates, cleanups, etc. and one real bugfix. 1.4.0 has actually seen testing in the form of loading the module, enjoying a view of a non-crashing X server (-retro too, I'm soo 80s today...) and thus deducting that the driver is bug-free. Which is more testing than previous releases have seen. Nonetheless, you may not want to control your nuclear power plants with this driver. Alan Coopersmith (1): Fill in COPYING file, add SubmittingPatches URL to README Peter Hutterer (19): Cope with XINPUT ABI 7. Fix module unloading. Remove unused bits from configure.ac Bump to 1.3.99 Purge CVS tags Remove refcount field, dropped from the server unifdef XFree86LOADER Replace LocalDevicePtr with InputInfoPtr. Drop close_proc, conversion_proc, reverse_conversion_proc Drop libc wrappers for free, malloc Require server 1.9, drop earlier ABI support Use GetMotionHistorySize() instead of driver-internal history Support input ABI 12 Bump minimum required server version to 1.10 Include xorg-server.h, not xorgVersion.h Reshuffle configure.ac to be more in-line with other modules Remove usage of sdkdir - not used by this driver Add 50-fpit.conf default configuration file. fpit 1.4.0 philip (1): fpit: minX/ maxX get wrongly initialized git tag: xf86-input-fpit-1.4.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-fpit-1.4.0.tar.bz2 MD5: 042c95fec145d8b57ca62714131ff3f1 xf86-input-fpit-1.4.0.tar.bz2 SHA1: 9305d30ae22d37c6b5bb975adc8ecda9b1d6c5e6 xf86-input-fpit-1.4.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-fpit-1.4.0.tar.gz MD5: 1f262074106c855b090295faadaedb80 xf86-input-fpit-1.4.0.tar.gz SHA1: 58c3b2f8306e5f2fa69a7636e2d74a88ca24e703 xf86-input-fpit-1.4.0.tar.gz pgpDT05xjDuQq.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-elographics 1.3.0
This driver is one of the legacy input drivers that you almost certainly don't want to use. Use the kernel driver instead (if one exists) or write one (if none exists). This release brings the usual input ABI updates, cleanups, etc. and one real bugfix. This release requires server 1.10 for the input ABI updates. 1.3.0 loads and complains that I don't have any elographics devices. Which is correct, hence the driver is clearly working correctly. Peter Hutterer (10): Bump to 1.2.99 unifdef XFree86LOADER Replace LocalDevicePtr with InputInfoPtr Require server 1.9, drop earlier ABI support Drop driver-specific motion history size handling. Drop close_proc, conversion_proc, reverse_conversion_proc Remove refcount field, dropped from the server Support input ABI 12 Require server 1.10 elographics 1.3.0 git tag: xf86-input-elographics-1.3.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-elographics-1.3.0.tar.bz2 MD5: 9c6616048cd589d6e8540c1d397f64ab xf86-input-elographics-1.3.0.tar.bz2 SHA1: 1f8480019607e0e366eb5ce4a3f3278fc164d7f7 xf86-input-elographics-1.3.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-elographics-1.3.0.tar.gz MD5: 389394af811d65241c17da7544fa4aaf xf86-input-elographics-1.3.0.tar.gz SHA1: 4b49781181d4e07507c3caf3fb4dd431c977a0cb xf86-input-elographics-1.3.0.tar.gz pgpN69v7dQWV0.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-hyperpen 1.4.0
This driver is one of the legacy input drivers and if you know users of this driver you might want to put them under a display cabinet in a museum because they must have rarity value by now. There has been exactly one fix (in 2007) to this driver since the modularisation in 2003. Use the kernel driver instead (if one exists) or write one (if none exists). This release brings the usual input ABI updates and cleanups. Needs server 1.10. Alan Coopersmith (1): Fill in COPYING AUTHORS files, add SubmittingPatches URL to README Manuel Reimer (1): Fixed indentation, dropped trailing whitespaces Peter Hutterer (26): Cope with XINPUT ABI 7. Bump to 1.3.99.1 Rename LocalDevicePtr references with InputInfoPtr. Remove libcwrappers for free() and malloc(). Remove RCS tags. Remove usages of XI_PRIVATE() Require server 1.9.99.1 Remove unused bits from configure.ac Unifdef pre ABI 12 conditions. Remove conversion procs and close_proc. Use GetMotionHistorySize() instead of the history size in the InputInfoRec. Specify Valuator modes on initialization. Remove xf86Verbose, XCONFIG_PROBED, nd XCONFIG_GIVEN. Remove read/write/tcflush libcwrappers. Remove unused wait_for_fd() define Remove ifdef check for XFREE86_LOADER Remove refcount from InputDriverRec. Hook the default options into the InputDriverRec. Remove unused HYPERPEN_SECTION_NAME define. Change the XI type from HYPERPEN to STYLUS. Remove less-than-useful comment. Adjust to new PreInit prototype for ABI 12. Don't call DEVICE_OFF during UnInit Reset local-private after freeing it. Require server 1.10 (through pkgconfig, not ABI checks) hyperpen 1.4.0 git tag: xf86-input-hyperpen-1.4.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-hyperpen-1.4.0.tar.bz2 MD5: 06c5b5e03daa042c543a38a175379db3 xf86-input-hyperpen-1.4.0.tar.bz2 SHA1: 28394e3de959012d2520220e4f9cec7c64cdee7f xf86-input-hyperpen-1.4.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-hyperpen-1.4.0.tar.gz MD5: 2784d89e63d4b161c35b6044dbea7585 xf86-input-hyperpen-1.4.0.tar.gz SHA1: 0068166cb2bcc5ae5e86a9b4e6dd55d62756198b xf86-input-hyperpen-1.4.0.tar.gz pgppPE5x6lSUe.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xproto 7.0.22
This package provides the headers and specification documents defining the X Window System Core Protocol, Version 11. It also includes a number of headers that aren't purely protocol related, but are depended upon by many other X Window System packages to provide common definitions and porting layer. This release provides a number of documentation improvements, a few new macros and new keysyms. Alan Coopersmith (8): Add comments to Xfuncproto.h noting required xproto versions for each macro spec: Markup VoidSymbol and NoSymbol with keysym instead of emphasis spec: Add cross-reference links in glossary to InputOnly InputOutput spec: Syntactic Conventions examples should not be separate list entries spec: move gt; outside emphasis to match lt; in note after error list spec: Add zone attributes to indexterm tags for more stable link ids spec: move id attributes for event definitions so fop can find them spec: Add more indexterm glossterm links Cyril Brulebois (3): Sort Latin 8 keysyms by codepoints. build: Add SIAddresses as a subdir of specs. Fix sorting by codepoint in Latin 2. Gaetan Nadon (3): Documentation: add Docbook external references support Install target dbs alongside generated documents Install xml versions of specs even if HAVE_XMLTO is false Jeremy Huddleston (2): Add _X_UNUSED attribute to designate unused variables and silence warnings Add _X_NONNULL macro to annotate when a function expects arguments to be non-null Matthieu Herrb (1): Fix __STDC_VERSION__ tests. Peter Hutterer (2): Add two more symbols for logging grab and window trees xproto 7.0.22 git tag: xproto-7.0.22 http://xorg.freedesktop.org/archive/individual/proto/xproto-7.0.22.tar.bz2 MD5: da0b0eb2f432b7cc1d665b05422a0457 xproto-7.0.22.tar.bz2 SHA1: 96d9b37d15591412a94dd0d3620008e20ef500ca xproto-7.0.22.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/xproto-7.0.22.tar.gz MD5: 18a8453a3120c465c8545f7a346c1c69 xproto-7.0.22.tar.gz SHA1: eeb042463b28a8f6f3820427e8ad53cb5c4f4a32 xproto-7.0.22.tar.gz pgpjBuiaZCjDa.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xproto 7.0.22
This package provides the headers and specification documents defining the X Window System Core Protocol, Version 11. It also includes a number of headers that aren't purely protocol related, but are depended upon by many other X Window System packages to provide common definitions and porting layer. This release provides a number of documentation improvements, a few new macros and new keysyms. Alan Coopersmith (8): Add comments to Xfuncproto.h noting required xproto versions for each macro spec: Markup VoidSymbol and NoSymbol with keysym instead of emphasis spec: Add cross-reference links in glossary to InputOnly InputOutput spec: Syntactic Conventions examples should not be separate list entries spec: move gt; outside emphasis to match lt; in note after error list spec: Add zone attributes to indexterm tags for more stable link ids spec: move id attributes for event definitions so fop can find them spec: Add more indexterm glossterm links Cyril Brulebois (3): Sort Latin 8 keysyms by codepoints. build: Add SIAddresses as a subdir of specs. Fix sorting by codepoint in Latin 2. Gaetan Nadon (3): Documentation: add Docbook external references support Install target dbs alongside generated documents Install xml versions of specs even if HAVE_XMLTO is false Jeremy Huddleston (2): Add _X_UNUSED attribute to designate unused variables and silence warnings Add _X_NONNULL macro to annotate when a function expects arguments to be non-null Matthieu Herrb (1): Fix __STDC_VERSION__ tests. Peter Hutterer (2): Add two more symbols for logging grab and window trees xproto 7.0.22 git tag: xproto-7.0.22 http://xorg.freedesktop.org/archive/individual/proto/xproto-7.0.22.tar.bz2 MD5: da0b0eb2f432b7cc1d665b05422a0457 xproto-7.0.22.tar.bz2 SHA1: 96d9b37d15591412a94dd0d3620008e20ef500ca xproto-7.0.22.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/xproto-7.0.22.tar.gz MD5: 18a8453a3120c465c8545f7a346c1c69 xproto-7.0.22.tar.gz SHA1: eeb042463b28a8f6f3820427e8ad53cb5c4f4a32 xproto-7.0.22.tar.gz pgpZeDbBpCsoi.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: option Ignore not working
) (**) default pointer: (accel) keeping acceleration scheme 1 (**) default pointer: (accel) acceleration profile 0 (**) default pointer: (accel) acceleration factor: 2.000 (**) default pointer: (accel) acceleration threshold: 4 (II) default pointer: Setting mouse protocol to ExplorerPS/2 (II) default pointer: ps2EnableDataReporting: succeeded (**) Option CoreKeyboard (**) default keyboard: always reports core events (**) Option Protocol standard (**) default keyboard: Protocol: standard (**) Option XkbRules base (**) default keyboard: XkbRules: base (**) Option XkbModel pc105 (**) default keyboard: XkbModel: pc105 (**) Option XkbLayout us (**) default keyboard: XkbLayout: us (**) Option CustomKeycodes off (**) default keyboard: CustomKeycodes disabled (II) XINPUT: Adding extended input device default keyboard (type: KEYBOARD) (II) UnloadModule: mouse (II) UnloadModule: kbd Again thank you for your help On Tue, Jun 7, 2011 at 7:18 PM, Peter Hutterer peter.hutte...@who-t.netwrote: On Tue, Jun 07, 2011 at 10:28:05AM -0400, William Roberts wrote: I am trying to get X to ignore a bunch of event nodes that other applications are using in a raw form. I want X to watch /dev/input/mice /dev/input/mouse0 and /dev/input/event5 ONLY. Below is my xorg.conf file: Please attach your Xorg.log so we can see what's going on here. Section ServerFlags Option AutoAddDevices false EndSection if you're not auto-adding devices, you don't need to ignore any since the server will only add devices that are listed in the config file. Also, IIRC the below can also be partially simplified Section InputClass Identifier ignore all MatchDevicePath /dev/input/event* Option Ignore on EndSection Section InputClass Identifier unignore Number 5 MatchDevicePath /dev/input/event5 Option Ignore off EndSection Cheers, Peter Section InputClass Identifier ign0 MatchDevicePath /dev/input/event0 Driver evdev Option Ignore on EndSection Section InputClass Identifier ign1 MatchDevicePath /dev/input/event1 Driver evdev Option Ignore on EndSection Section InputClass Identifier ign3 MatchDevicePath /dev/input/event3 Driver evdev Option Ignore on EndSection Section InputClass Identifier ign4 MatchDevicePath /dev/input/event4 Driver evdev Option Ignore on EndSection Section Device Identifier vfb Driver fbdev EndSection Section InputDevice Identifier mouse0 Driver mouse Option Protocol auto Option Device/dev/input/mice EndSection Section InputDevice Identifier kb0 Driver evdev Option XkbLayout us,cz Option XkbVariant ,qwerty Option Device/dev/input/event5 EndSection Thank you for your help in advance! ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: peter.hutte...@who-t.net -- Respectfully, William C Roberts 585-455-1883 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] inputproto 2.0.2
This stable update fixes an error in the XIMaskLen definition and include errors if the client did not include stdint.h before the XI2 headers. Plus, a few typos fixed in the protocol specification. Alexandre Julliard (1): XI2.h: Fix off-by-one error in the XIMaskLen definition. Chase Douglas (1): Include stdint.h Fernando Carrijo (1): Fix typos in XIproto.txt Peter Hutterer (1): inputproto 2.0.2 git tag: inputproto-2.0.2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.0.2.tar.bz2 MD5: 07d54ae098ed4e6dce472f6ef3de05ce inputproto-2.0.2.tar.bz2 SHA1: a34c01c67aa2ed9058ff19ace0041978b1d8d711 inputproto-2.0.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.0.2.tar.gz MD5: 40c57a8dae6d29842ff17da1ae06eddd inputproto-2.0.2.tar.gz SHA1: b25d2ee3d27f10d552a0f24819c61a21ed7ca5cf inputproto-2.0.2.tar.gz pgpakcC6XPw95.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] inputproto 2.0.2
This stable update fixes an error in the XIMaskLen definition and include errors if the client did not include stdint.h before the XI2 headers. Plus, a few typos fixed in the protocol specification. Alexandre Julliard (1): XI2.h: Fix off-by-one error in the XIMaskLen definition. Chase Douglas (1): Include stdint.h Fernando Carrijo (1): Fix typos in XIproto.txt Peter Hutterer (1): inputproto 2.0.2 git tag: inputproto-2.0.2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.0.2.tar.bz2 MD5: 07d54ae098ed4e6dce472f6ef3de05ce inputproto-2.0.2.tar.bz2 SHA1: a34c01c67aa2ed9058ff19ace0041978b1d8d711 inputproto-2.0.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.0.2.tar.gz MD5: 40c57a8dae6d29842ff17da1ae06eddd inputproto-2.0.2.tar.gz SHA1: b25d2ee3d27f10d552a0f24819c61a21ed7ca5cf inputproto-2.0.2.tar.gz pgp3hstBUGq4c.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: option Ignore not working
On Tue, Jun 07, 2011 at 10:28:05AM -0400, William Roberts wrote: I am trying to get X to ignore a bunch of event nodes that other applications are using in a raw form. I want X to watch /dev/input/mice /dev/input/mouse0 and /dev/input/event5 ONLY. Below is my xorg.conf file: Please attach your Xorg.log so we can see what's going on here. Section ServerFlags Option AutoAddDevices false EndSection if you're not auto-adding devices, you don't need to ignore any since the server will only add devices that are listed in the config file. Also, IIRC the below can also be partially simplified Section InputClass Identifier ignore all MatchDevicePath /dev/input/event* Option Ignore on EndSection Section InputClass Identifier unignore Number 5 MatchDevicePath /dev/input/event5 Option Ignore off EndSection Cheers, Peter Section InputClass Identifier ign0 MatchDevicePath /dev/input/event0 Driver evdev Option Ignore on EndSection Section InputClass Identifier ign1 MatchDevicePath /dev/input/event1 Driver evdev Option Ignore on EndSection Section InputClass Identifier ign3 MatchDevicePath /dev/input/event3 Driver evdev Option Ignore on EndSection Section InputClass Identifier ign4 MatchDevicePath /dev/input/event4 Driver evdev Option Ignore on EndSection Section Device Identifier vfb Driver fbdev EndSection Section InputDevice Identifier mouse0 Driver mouse Option Protocol auto Option Device/dev/input/mice EndSection Section InputDevice Identifier kb0 Driver evdev Option XkbLayout us,cz Option XkbVariant ,qwerty Option Device/dev/input/event5 EndSection Thank you for your help in advance! ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: peter.hutte...@who-t.net ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libXi 1.4.3
[My apologies for the duplicate, I managed to add some bogus chars on the xorg-announce address] libXi are is the library for the X Input Extension. This stable release brings a few man page fixes and three actual code fixes: two 64 bit issues and one invalid memory access fix. Matthieu Herrb (1): Fix XISelectEvents on 64 bits, strict alignement architectures. Peter Hutterer (8): Allocate enough memory for raw events + extra data. XIChangeHierarchy: Return Success early if no actual changes are requested. man: fix typo, layout in XGetExtensionVersion.man man: fix missing comma in XIGrabEnter man page Use Data, not Data32 in XIPassiveGrabDevice man: Fix wrong event names in XIGrabButton. man: Fix typo in XIChangeProperty libXi 1.4.3 git tag: libXi-1.4.3 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.3.tar.bz2 MD5: 792e8a7ddc7175911d69f823d38eaff6 libXi-1.4.3.tar.bz2 SHA1: c66cfdee74e8d169a7992b5f257395e653ca761b libXi-1.4.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.3.tar.gz MD5: 81da84a6a12acec81dda0e200e8b8995 libXi-1.4.3.tar.gz SHA1: 246948d21026d797450066626dee84178dd8c86d libXi-1.4.3.tar.gz pgpnnXIDUj66T.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] libXi 1.4.3
libXi are is the library for the X Input Extension. This stable release brings a few man page fixes and three actual code fixes: two 64 bit issues and one invalid memory access fix. Matthieu Herrb (1): Fix XISelectEvents on 64 bits, strict alignement architectures. Peter Hutterer (8): Allocate enough memory for raw events + extra data. XIChangeHierarchy: Return Success early if no actual changes are requested. man: fix typo, layout in XGetExtensionVersion.man man: fix missing comma in XIGrabEnter man page Use Data, not Data32 in XIPassiveGrabDevice man: Fix wrong event names in XIGrabButton. man: Fix typo in XIChangeProperty libXi 1.4.3 git tag: libXi-1.4.3 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.3.tar.bz2 MD5: 792e8a7ddc7175911d69f823d38eaff6 libXi-1.4.3.tar.bz2 SHA1: c66cfdee74e8d169a7992b5f257395e653ca761b libXi-1.4.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.3.tar.gz MD5: 81da84a6a12acec81dda0e200e8b8995 libXi-1.4.3.tar.gz SHA1: 246948d21026d797450066626dee84178dd8c86d libXi-1.4.3.tar.gz pgp1I871g4htm.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libXi 1.4.3
[My apologies for the duplicate, I managed to add some bogus chars on the xorg-announce address] libXi are is the library for the X Input Extension. This stable release brings a few man page fixes and three actual code fixes: two 64 bit issues and one invalid memory access fix. Matthieu Herrb (1): Fix XISelectEvents on 64 bits, strict alignement architectures. Peter Hutterer (8): Allocate enough memory for raw events + extra data. XIChangeHierarchy: Return Success early if no actual changes are requested. man: fix typo, layout in XGetExtensionVersion.man man: fix missing comma in XIGrabEnter man page Use Data, not Data32 in XIPassiveGrabDevice man: Fix wrong event names in XIGrabButton. man: Fix typo in XIChangeProperty libXi 1.4.3 git tag: libXi-1.4.3 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.3.tar.bz2 MD5: 792e8a7ddc7175911d69f823d38eaff6 libXi-1.4.3.tar.bz2 SHA1: c66cfdee74e8d169a7992b5f257395e653ca761b libXi-1.4.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.3.tar.gz MD5: 81da84a6a12acec81dda0e200e8b8995 libXi-1.4.3.tar.gz SHA1: 246948d21026d797450066626dee84178dd8c86d libXi-1.4.3.tar.gz pgpXrjYlcalQp.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: multiple keyboards with different bindings
On Thu, May 26, 2011 at 07:51:47AM -0700, Peter Sanford wrote: Ahh. Under GDM I have the problem, but with startx the two keyboards are configured correctly. I guess I'll take this issue over to the fine GDM folks. CC-ing xorg list, so the solution is public. Cheers, Peter On Tue, May 24, 2011 at 8:24 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Thu, May 19, 2011 at 06:56:09PM -0700, Peter Sanford wrote: I went ahead and changed the config like you suggested (separate xorg.conf.d files using MatchUSBID). I have the same problem as before: which ever config is applied second get applied to both keyboards (overriding the first setting). I confirmed this by testing with a different keyboard that caused the configuration to be applied in the opposite order from my first test. Does this mean that the XkbOptions are being applied to the virtual core keyboard instead of the slave keyboards? Here is the log output: [ 990.609] (**) Apple Inc. Apple Internal Keyboard / Trackpad: Applying InputClass evdev keyboard catchall [ 990.609] (**) Apple Inc. Apple Internal Keyboard / Trackpad: Applying InputClass Apple Keyboards [ 990.609] (II) Using input driver 'evdev' for 'Apple Inc. Apple Internal Keyboard / Trackpad' [ 990.609] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [ 990.609] (**) Apple Inc. Apple Internal Keyboard / Trackpad: always reports core events [ 990.609] (**) Apple Inc. Apple Internal Keyboard / Trackpad: Device: /dev/input/event8 [ 990.610] (--) Apple Inc. Apple Internal Keyboard / Trackpad: Found keys [ 990.610] (II) Apple Inc. Apple Internal Keyboard / Trackpad: Configuring as keyboard [ 990.610] (**) Option config_info udev:/sys/devices/pci:00/:00:06.0/usb4/4-3/4-3:1.0/input/input8/event8 [ 990.610] (II) XINPUT: Adding extended input device Apple Inc. Apple Internal Keyboard / Trackpad (type: KEYBOARD) [ 990.610] (**) Option xkb_rules evdev [ 990.610] (**) Option xkb_model pc105 [ 990.610] (**) Option xkb_layout us [ 990.610] (**) Option xkb_options altwin:swap_lalt_lwin,caps:super ... [ 990.753] (**) KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle: Applying InputClass evdev keyboard catchall [ 990.753] (**) KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle: Applying InputClass Keyboard Catch All [ 990.753] (II) Using input driver 'evdev' for 'KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle' [ 990.753] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [ 990.753] (**) KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle: always reports core events [ 990.753] (**) KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle: Device: /dev/input/event9 [ 990.754] (--) KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle: Found keys [ 990.754] (II) KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle: Configuring as keyboard [ 990.754] (**) Option config_info udev:/sys/devices/pci:00/:00:06.1/usb2/2-4/2-4.2/2-4.2:1.0/input/input9/event9 [ 990.754] (II) XINPUT: Adding extended input device KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle (type: KEYBOARD) [ 990.754] (**) Option xkb_rules evdev [ 990.754] (**) Option xkb_model pc105 [ 990.754] (**) Option xkb_layout us [ 990.754] (**) Option xkb_options caps:super,terminate:ctrl_alt_bksp You can see in the log that the apple keyboard got the Apple Keyboards input class and the kinesis keyboard got the Keyboard Catch All class. But when I actually use the keyboards both act as if they are using the Keyboard Catch All class. is this on a plain X server or with a desktop environment running? if so, does the DE overwrite the keyboard settings? Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: psanf...@gmail.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: multiple keyboards with different bindings
On Thu, May 19, 2011 at 06:56:09PM -0700, Peter Sanford wrote: I went ahead and changed the config like you suggested (separate xorg.conf.d files using MatchUSBID). I have the same problem as before: which ever config is applied second get applied to both keyboards (overriding the first setting). I confirmed this by testing with a different keyboard that caused the configuration to be applied in the opposite order from my first test. Does this mean that the XkbOptions are being applied to the virtual core keyboard instead of the slave keyboards? Here is the log output: [ 990.609] (**) Apple Inc. Apple Internal Keyboard / Trackpad: Applying InputClass evdev keyboard catchall [ 990.609] (**) Apple Inc. Apple Internal Keyboard / Trackpad: Applying InputClass Apple Keyboards [ 990.609] (II) Using input driver 'evdev' for 'Apple Inc. Apple Internal Keyboard / Trackpad' [ 990.609] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [ 990.609] (**) Apple Inc. Apple Internal Keyboard / Trackpad: always reports core events [ 990.609] (**) Apple Inc. Apple Internal Keyboard / Trackpad: Device: /dev/input/event8 [ 990.610] (--) Apple Inc. Apple Internal Keyboard / Trackpad: Found keys [ 990.610] (II) Apple Inc. Apple Internal Keyboard / Trackpad: Configuring as keyboard [ 990.610] (**) Option config_info udev:/sys/devices/pci:00/:00:06.0/usb4/4-3/4-3:1.0/input/input8/event8 [ 990.610] (II) XINPUT: Adding extended input device Apple Inc. Apple Internal Keyboard / Trackpad (type: KEYBOARD) [ 990.610] (**) Option xkb_rules evdev [ 990.610] (**) Option xkb_model pc105 [ 990.610] (**) Option xkb_layout us [ 990.610] (**) Option xkb_options altwin:swap_lalt_lwin,caps:super ... [ 990.753] (**) KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle: Applying InputClass evdev keyboard catchall [ 990.753] (**) KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle: Applying InputClass Keyboard Catch All [ 990.753] (II) Using input driver 'evdev' for 'KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle' [ 990.753] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [ 990.753] (**) KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle: always reports core events [ 990.753] (**) KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle: Device: /dev/input/event9 [ 990.754] (--) KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle: Found keys [ 990.754] (II) KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle: Configuring as keyboard [ 990.754] (**) Option config_info udev:/sys/devices/pci:00/:00:06.1/usb2/2-4/2-4.2/2-4.2:1.0/input/input9/event9 [ 990.754] (II) XINPUT: Adding extended input device KINESIS FREESTYLE KB700 KB700 Kinesis Freestyle (type: KEYBOARD) [ 990.754] (**) Option xkb_rules evdev [ 990.754] (**) Option xkb_model pc105 [ 990.754] (**) Option xkb_layout us [ 990.754] (**) Option xkb_options caps:super,terminate:ctrl_alt_bksp You can see in the log that the apple keyboard got the Apple Keyboards input class and the kinesis keyboard got the Keyboard Catch All class. But when I actually use the keyboards both act as if they are using the Keyboard Catch All class. is this on a plain X server or with a desktop environment running? if so, does the DE overwrite the keyboard settings? Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: tablets using evdev
On Wed, May 18, 2011 at 10:30:11PM -0400, Jimmy Hon wrote:
The Short:
I have a tablet and it didn't work with the evdev driver. So I
hacked the evdev input driver to work with it. Hacks are bad, so how
should I go about getting real fixes?
The Long:
I bought a tablet from MonoPrice (Item 6251,
http://www.monoprice.com/products/product.asp?c_id=108cp_id=10841cs_id=1084101p_id=6251seq=1format=2).
In lsusb, it identifies as:
5543:0064 UC-Logic Technology Corp. Aiptek HyperPen 1U.
/proc/bus/input/devices says:
I: Bus=0003 Vendor=5543 Product=0064 Version=0110
N: Name=UC-LOGIC TWA60
P: Phys=usb-:00:12.2-2.1.2/input0
S:
Sysfs=/devices/pci:00/:00:12.2/usb1/1-2/1-2.1/1-2.1.2/1-2.1.2:1.0/input/input73
U: Uniq=
H: Handlers=mouse5 event13
B: PROP=0
B: EV=1f
B: KEY=c03 3f0001 0 0 0 0
B: REL=303
B: ABS=10f
B: MSC=10
The tablet didn't work correctly when evdev drove it. Playing with
xinput test, it turns out the tablet was reporting the x/y
coordinates on valuator 2 and 3, and not on 0 and 1. The pen
sensitivity is reported as evaluator 4. So valuator 2, 3, and 4 were
reporting data when I moved then pen around.
So I wanted evdev to ignore the first two valuators. I did this by
cheating and changed the ABS initialization code in
EvdevAddAbsClass() to start the for loop at ABS_Z instead for ABS_X
when it's checking the abs_bitmask). So basically, if
/proc/bus/input/devices reported ABS=10c instead of ABS=10f,
I would have been fine.
you need HID_QUIRK_MULTI_INPUT in the kernel for this device. See kernel
commit e1f092102f65e424be40c318a0fab7bb6e34194f for example.
once that's in, you get two kernel devices, the first one mute but the
second one with the right axis enumeration.
Cheers,
Peter
To get the wheel emulation working, in EvdevWheelEmuFilterMotion(),
I changed the switch statement to check pEvdev-axis_map[pEv-code]
instead of just pEv-code. It's a similar idea as the ABS
differential measurement code just above the switch statement. You
want to check which axis the values will be eventually reported as.
This works fine for _me_, since the tablet is the only input device
that's in absolute mode. My normal mouse and trackball use relative
mode, and those code paths have not been modified.
So if I want this tablet to work for real what's the proper way to do it?
1. Should the kernel driver not report the two unused valuators?
(Make it report ABS=10c instead of ABS=10f)
2. Does the evdev xorg driver have an ability to remap axes?
3. Can the evdev xorg driver have addditional options to blacklist
some of the valuators?
4. Should any of this be done in the evdev xorg driver? Or is it
more appropriate to have a specific tablet driver?
I know there is the wizardpen xorg driver, which supports this
tablet. But it's not as featureful as evdev. There's no wheel
emulation, and no Properties to changes at runtime. (I've been
changing the Calibration property, when I switch between single
monitor vs dual monitors)
If this type of support should be a tablet specific xorg driver, is
there a master tablet driver? (i.e. like how evdev is the master
driver for all mice and keyboards?)
I've seen the aiptek, hyperpen, wizardpen, and wacom drivers. Why
are there so many tablet drivers? What makes each driver so special?
(I tried google and also perusing the xorg.freedesktop.org site, but
I couldn't pinpoint the differences between the drivers). Having so
many tablet drivers makes me think that there is going to be a lot
of code duplication if they were all going to have a wheel emulation
feature. Is there a way to put the wheel emulation logic into a
library, and have all the drivers share that?
Jimmy
P.S. Should this be posted on xorg-devel too?
My hacks look like this:
diff -ur xf86-input-evdev-2.6.0/src/emuWheel.c
xf86-input-evdev-2.6.0-dev/src/emuWheel.c
--- xf86-input-evdev-2.6.0/src/emuWheel.c2010-12-20
19:19:16.0 -0500
+++ xf86-input-evdev-2.6.0-dev/src/emuWheel.c2011-05-18
04:14:18.207068902 -0400
@@ -125,7 +125,7 @@
value -= oldValue; /* make value into a differential
measurement */
}
-switch(pEv-code) {
+switch(pEvdev-axis_map[pEv-code]) {
/* ABS_X has the same value as REL_X, so this case catches both */
case REL_X:
diff -ur xf86-input-evdev-2.6.0/src/evdev.c
xf86-input-evdev-2.6.0-dev/src/evdev.c
--- xf86-input-evdev-2.6.0/src/evdev.c2011-01-05
17:35:27.0 -0500
+++ xf86-input-evdev-2.6.0-dev/src/evdev.c2011-05-16
00:52:41.485952421 -0400
@@ -1303,7 +1303,7 @@
memset(pEvdev-old_vals, -1, num_axes * sizeof(int));
atoms = malloc(pEvdev-num_vals * sizeof(Atom));
-for (axis = ABS_X; i MAX_VALUATORS axis = ABS_MAX; axis++) {
+for (axis = ABS_Z; i MAX_VALUATORS axis = ABS_MAX; axis++) {
pEvdev-axis_map[axis] = -1;
if (!TestBit(axis, pEvdev-abs_bitmask))
Re: mieqProcessDeviceEvent make calls to mieqEnque with signals enabled - freezes Xorg server - multi-screen
On Tue, May 17, 2011 at 05:13:37PM -0500, Donald Kayser wrote: Thanks for the quick response Jeremy. I was aware that I would miss events during this test, but that was better than freezing. I have not tried 1.10.x, but I will. We are trying to release a product soon and changing to a new server and distribution is not straightforward or the best move on our part. I might have to consider any other solution for the short term. I am glad to hear that we are not the only ones to have this problem and that it might already be solved. I will look further at 1.10.x and go from there. I think this bug may still be there (possibly in a different incarnation) in 1.10. I haven't had any success reproducing it yet though. I know at least one of these got fixed in the last couple of server versions, but I can't seem to find the commit for it now. I suppose the quickest fix is to put OsBlockSignals() and OsReleaseSignals() around the part that must not be interrupted and rewrite it to be as short as possible. If you have a good description of the bug I'd love to hear it so we can look at a proper fix. Cheers, Peter On May 17, 2011, at 4:49 PM, Jeremy Huddleston wrote: Ignoring SIGIO will just result in dropped events. I seem to vaguely recall that this issue was addressed at some point in the past year or two since 1.7.x was active. Have you tried 1.10.x or master? On May 17, 2011, at 13:34, Donald Kayser wrote: I am developing a system that include's the debian/squeeze distribution of xorg-server, version 1.7.7. I have come across a scenario where mouse movements on one screen and a touch on another screen will cause the Xorg process to freeze in an infinite loop in the function mieqProcessInputEvents(). I have traced the problem down to a small window during which a call to mieqProcessDeviceEvent can be interrupted by a signal and mess up the miEventQueue.head and tail. It appears that in some place in this stack a new event is being enqueued while the screen is changing and device messages get swapped to the wrong screen and back and forth. I put a global variable in mieqProcessDeviceEvent to indicate to mieqEnqueue to ignore data until finished. This has solved the problem as a test. I am now writing the code to ignore the SIGIO signal during mieqProcessDeviceEvent and test this approach also. Does anyone have a similar problem or advice? Thanks Donald Kayser xorg at kayser dot net ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: jerem...@freedesktop.org ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: x...@kayser.net ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: peter.hutte...@who-t.net ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: evdev: Attach touchscreen to X screen
On Mon, May 09, 2011 at 02:40:01PM +0200, Stephan Josel wrote: We're trying to get a multi-touchscreen (multiple touchscreens not multi touch) setup working with the evdev driver in Ubuntu (Natty Narwhal, 11.04). Basically, the touchscreens are configured and working except that the mapping to the correct X screen is wrong. We set up 5 touchscreens in a row (Xorg ServerLayout RightOf) with Xinerama enabled and their corresponding touchscreen inputdevices. Using xinput we are able to create a pointer for each of the touchscreens. The following is observed then: When touching any screen, the resulting movement of the pointer is only displayed on the first X screen (there are 5 pointers visible then on this screen). This is not at all the desired behavior. We would like to attach a touchscreen to a specific X screen. Unfortunately, we found no way to tell the evdev driver to map a InputDevice to a X screen. Older versions of the driver provided an option AbsoluteScreen but the latest version hasn't anything like this. I know that the evtouch driver would provide a ScreenNo option, however evtouch is not available for Natty Narwhal. We also experimented with the Xorg coordinate transformation matrix, but with the result that the mouse movements where still on the first X screen. So my question is: How do I tell the evdev driver to map an InputDevice to a specific X screen? Is there an option line in xorg.conf or is there any method via xinput? tbh, I don't think we have anything in place right now for multiple screens. Multiple outputs - yes (the transformation matrix) but not multiple screens. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: eGalax Touchscreen calibration problems
On Mon, Apr 18, 2011 at 12:38:23PM -0400, Ken Emmons Jr. wrote: I am having issues calibrating and swapping axes on an eGalax touchscreen. Xorg does seem to recognize the device as an input device and seemingly tries to move the cursor appropriately to its wrong calibration. I had to pass usbhid.quirks=0xeef:0x1:0x40 to the kernel boot parameters to get the kernel HID driver to handle the touchscreen properly. Prior to this it did not work at all. I see valid event interfaces and can in fact get events from them using the evtest.c program at a console. When I try to use evdev driver configured to an event interface (using xorg.conf) xorg logs state that evdev doesn't know what to do with the device. When I use the evtouch driver it just crashes. Most of the help online is using the evtouch driver and this really isn't doing me any good as a result. From what I can see and have read this driver is going away anyhow. It is probably worth noting that when I type xinput list I see no notice of the touchscreen, but that there is just a configured mouse. I suspect that the HAL layer is somehow doing something with combining my regular mouse and my HID touchscreen and xorg is just interpreting that. If this is the case should I be doing my calibrations from the HAL, or is that just passing the data to the Xorg server anyhow? I am using Debian Lenny on a embedded PowerPC computer and I am having problems finding information since most of it is circa 2008-2009. At this point I cannot upgrade the distribution, although that may be a possibility in the future. Xorg version 1.4.2 Any ideas? I'd be happy to do any reading, but I am jumping back and forth between different projects reading conflicting information at this point. newer kernels and evdev versions shouldn't have any problems with the eGalax screens. the kernel patch does pretty much what you passed to the boot params. Can't remember if evdev needed fixes for it but the general rule is that if it doesn't work in your current version and you can't upgrade, you're stuck. your only chance is to figure out why evdev can't use the device (usually that's because a missing button on the device that evdev needs to recognise it). then you can try to hack it up there and hardcode the button mappings. HAL does nothing other than shouting hey, here's a device for you and passing optional configuration options. anything more fancy than that is in the driver. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: evdev devices in xorg.conf
On Tue, May 03, 2011 at 07:47:24AM +0200, Zoltan Szecsei wrote: On 2011-05-03 07:32, Peter Hutterer wrote: On Sat, Apr 30, 2011 at 07:52:42PM +0200, Zoltan Szecsei wrote: Kubuntu 11.04 fresh install I'm trying to set up a 3-seat multiseat system but for now I have installed only 1 VGA card and want to get the correct xorg.conf contents before I add the other two seats. The system comes up OK, but after a minute or two, the desktop freezes. I'd be grateful if someone could pass comment on the attached xorg.conf and Xorg.0.log files. Thanks in advance, Zoltan -- [...] [11.444] (II) No input driver/identifier specified (ignoring) [ 221.625] (WW) NVIDIA(0): WAIT (2, 6, 0x8000, 0xf7f7, 0x0004fe20) [ 222.235] [mi] EQ overflowing. The server is probably stuck in an infinite loop. looks like the nvidia driver is at fault here. note that this is not an evdev bug, evdev just exposes it because it tries to enqueue more input events but the server isn't processing them anymore. Cheers, Peter Hi All, I've got it to a stage where I get the KDM login screen with full mouse keyboard functionality. After I login, the mouse keyboard drops out before the desktop appears. Using ssh I get into the system and check Xorg.0.log, to find that the 'EE' error points to: (EE) PreInit returned 8 for Logitech USB Receiver that just means that the device didn't get added for some reason. Nothing that should affect the working of the server (other than that you obviously can't use this device). If you ssh in before, you'll probably notice that this line is already in the log while you're logging in. from your last backtrace, it's the graphics driver that hangs. Cheers, Peter I can include the dmesg, Xorg.0.log and xorg.conf files if anyone would like. BTW: In ubuntu 6.06 (2.6.15-29) with gdm, I used to have pci=nommconf and vmalloc=256M in the bootstring - I'm using default bootstrings for this install. Is this a problem? TIA, Zoltan ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: When was xrender 0.11 introduced?q
On Tue, May 03, 2011 at 08:22:08PM +0200, Clemens Eisserer wrote: Hi, Does anybody remember which xorg-server version brought support for xrender 0.11? commit c65280ce8df4836bd7424a90482e8aa00ab6f447 Refs: xorg-server-1.8.99.904-16-gc65280c Cheers, Peter I think about not using some paths for render 0.11, however if its too recent I would probably exclude more xorg-server versions than required. Thanks, Clemens ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: egalax USB touchscreen problems (EVDEV Question)
On Wed, Apr 20, 2011 at 11:17:07AM -0400, Ken Emmons Jr. wrote: I found some references to the EVDEV driver in the archives of the mailing list having issues with the touch event code (330) and my touchscreen is also emitting this event. The latest version of xorg changelog states that some work was done to try and fix BTN_TOUCH for touchscreens. Do I need to upgrade Xorg to test this, or should I just get source for evdev and build that against my current Xorg version? Current evdev won't work against your server, you'd need to either backport the fixes or update your server too. But yes, this issue should be fixed. Cheers, Peter I've attached the evtest.c output for reference: ./evtest /dev/input/event1 Input driver version is 1.0.0 Input device ID: bus 0x3 vendor 0xeef product 0x1 version 0x210 Input device name: eGalax Inc. USB TouchController Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 320 (ToolPen) Event code 330 (Touch) Event type 3 (Absolute) Event code 0 (X) Value 3345 Min 30 Max 4040 Event code 1 (Y) Value 2178 Min 60 Max 4035 Event type 4 (Misc) Event code 4 (ScanCode) Testing ... (interrupt to exit) Event: time -1139204008.401203, type 4 (Misc), code 4 (ScanCode), value d0042 Event: time -1139204008.401215, type 1 (Key), code 330 (Touch), value 1 Event: time -1139204008.401219, type 3 (Absolute), code 0 (X), value 2071 Event: time -1139204008.401222, type 3 (Absolute), code 1 (Y), value 1648 Event: time -1139204008.401224, -- Report Sync Event: time -1139204008.407187, type 3 (Absolute), code 0 (X), value 2076 Event: time -1139204008.407192, type 3 (Absolute), code 1 (Y), value 1645 Event: time -1139204008.407194, -- Report Sync Event: time -1139204008.413181, type 4 (Misc), code 4 (ScanCode), value d0042 Event: time -1139204008.413187, type 1 (Key), code 330 (Touch), value 0 Event: time -1139204008.413194, -- Report Sync When I assign this device to evdev via xorg.conf or using hal I get the message: (WW) eGalax Inc. USB TouchController: Don't know how to use device (II) UnloadModule: evdev From: xorg-bounces+kemmons=qatech@lists.freedesktop.org [mailto:xorg-bounces+kemmons=qatech@lists.freedesktop.org] On Behalf Of Ken Emmons Jr. Sent: Tuesday, April 19, 2011 11:54 AM To: xorg@lists.freedesktop.org Subject: egalax USB touchscreen problems Hello, I tried to post this yesterday but I am not sure if it showed up on the mailing list. I am trying to get an egalax touchscreen working on an embedded PowerPC target using Debian Lenny distribution and custom compiled kernel for 2.6.30.3. Xorg is 1.4.2 and evdev is 2.0.8 (See log below). Anyhow I have more data: Using HAL I was able to pass some information to the X server using this file: ?xml version=1.0 encoding=ISO-8859-1? !-- 10-synaptics.fdi is claiming all input.touchpad's as its own. This file is meant to be loaded afterwards and to undo any wrong assignments it did. -- deviceinfo version=0.2 device !--match key=info.capabilities contains=input.touchpad -- match key=info.product contains=eGalax merge key=input.x11_driver type=stringevdev/merge merge key=input.x11_options.Calibration type=string32 3990 48 3990/merge merge key=input.x11_options.InvertX type=stringtrue/merge /match !--/match -- /device /deviceinfo The xorg server didn't seem to like loading the evdev driver though, and seems to be interpreting my touchscreen as a mouse with absolute coordinates, and the wrong calibration. See the following output: Log file output pertaining to input (I have a USB mouse and the USB touchscreen plugged in): (WW) Configured Mouse: No Device specified, looking for one... (II) Configured Mouse: Setting Device option to /dev/input/mice (--) Configured Mouse: Device: /dev/input/mice (==) Configured Mouse: Protocol: Auto (**) Option CorePointer (**) Configured Mouse: always reports core events (**) Option Device /dev/input/mice (==) Configured Mouse: Emulate3Buttons, Emulate3Timeout: 50 (**) Configured Mouse: ZAxisMapping: buttons 4 and 5 (**) Configured Mouse: Buttons: 9 (**) Configured Mouse: Sensitivity: 1 (**) Option CoreKeyboard (**) Generic Keyboard: always reports core events (**) Option Protocol standard (**) Generic
Re: Every newcomers to X think that servers and clients are reversed because they are
On Wed, Apr 20, 2011 at 06:21:05PM -0400, Paul Dufresne wrote: I'll try to give a more precise description of how I imagine things works right now, and how I imagine they should work. Currently, I believe things goes about like this: When you start an X application (that we call the X client), it read There is no such thing as an X application. Applications may be X clients or may be not, or may be in some circumstances, or may be multiple X clients in one application. Any proces that connects to an X server is an X client, X has no concept of applications. In fact, some processes will open two client connections and the X server doesn't even know they belong to the same process. the $DISPLAY environment string to know the host where the X server it should call is. That is by convention (default Xlib behaviour), not by requirement. It is perfectly valid for an application to ignore $DISPLAY and hardcode a connection with Display *dpy = XOpenDisplay(myserver-name); It then goes on to connect to this host, asking to speak on the X server on this host. The X server open a new window that talk to the X application, through a new port. Windows are requested by clients and there are several X clients that do not open windows (xinput, xsetwacom and synclient being the ones I work with frequently, there are others). Windows in X are also not what you may perceive as window. An X Window is a rectangular (ignoring the SHAPE extension) area on the screen that can be painted into. With a bit of effort on the _client's_ behalf, this window can be made to look like what you then perceive as window. To X, the window is still a rectangular area that has been painted into. X has no concepts of buttons, checkboxes, or _any_ other widgets either, they're purely client-side. Cheers, Peter What I would do: -create a new program that I would call the X server. This program would have a configuration that would looks like: User_Group Authorized X application secretaryLibreOffice programmer xterm ownerxterm ownerLibreOffice -I would move the code that sits and wait for new clients to connect, from what we was calling the X server, to this new X server -I would move and modify a bit the code to authenticate, to this new X server -I would rename the program we used to call the X server, to be called the X Client, and make it be a program similar to xdm So after my changes: When you would start the X client, you would be asked to enter your username, password, and select the X server you want to connect to. After connecting and authenticating to the X server with your username, the server would send you the list of authorized X application you are allowed to run, depending on the user group the username is in. Then, for each application you choose to open, the X client would open a new window to speak with this X application on a new port. It would also send a request to the X server, to request it to launch the X application on the host where the X application is. Not a very big change... but I guess it does change quite a bit how you use the computer. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: peter.hutte...@who-t.net ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Touchpad not recognized
On Tue, Apr 19, 2011 at 09:57:27AM +0200, Xianwen Chen wrote:
Hi there,
I'm runnig Arch Linux X64 on a Dell Latitude E5410. The version of X
Server is 1.10.1.
The laptop's touchpad is not recognized as xinput list only shows following:
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer
(2)]
⎜ ↳ PS/2 Generic Mouse id=12 [slave pointer
(2)]
if you see this line, it usually means the kernel
doesn't support your specific touchpad. That's the part that needs fixing.
Once supported, it's likely to just work.
Cheers,
Peter
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ Sleep Button id=9 [slave keyboard (3)]
↳ Laptop_Integrated_Webcam_2M id=10 [slave keyboard
(3)]
↳ AT Translated Set 2 keyboard id=11 [slave keyboard
(3)]
↳ Dell WMI hotkeys id=13 [slave keyboard
(3)]
xf86-input-synaptics (1.4.0-2) and xf86-input-evdev (2.6.0-3) are
installed. The system runs on a 2.6.38.2 kernel.
Does someone have an idea on how to fix the problem? ;)
Xianwen
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: peter.hutte...@who-t.net
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Every newcomers to X think that servers and clients are reversed because they are
On Tue, Apr 19, 2011 at 11:36:17PM -0400, Paul Dufresne wrote: For years I have heard of how we must rethink what is the server and what are the clients when coming to X. But the more I think about it, the more I conclude X is wrong, and should reverse their order. What you call the X server should be an X client. You could think as the applications being the server... but I guess this is not really correct either. An X server should wait for clients to connect (yes, that point X does the right thing). But what is now the client, should have a list of X server (that does not exist yet) to connect to. When you connect to an X server, you should be given a list of applications allowable to connect to. Then, you would be able to open one of the applications available, at your choice. From there, a new connection would be open between the application and the client (what is now called the X server), pretty much like a new connection is created right now. This would make X system much more useful I believe, because it would fit the way people expect server and clients to work. Then making a multi-user game would be pretty obvious, because it would just means to add some new avatar each time a new X client would connect to the game application on a given X server. At least, that the way I think it should be. sigh. I never understood why people claim that one must rethink server/client when it comes to X. X server and client notion are _not_ reversed. The X server sits there, waiting for connections. Just like FTP servers. The X server provides auth mechanisms, restricting which clients can connect. Just like FTP servers. Once a client connects, the server provides a specific protocol to communicate. Just like FTP servers. The protocol allows access to certain resources local to the machine. Just like FTP servers. (in the FTP server's case the resources are files, in the X server's case they are hardware resources) The clients can upload data (e.g. pixel data) and download data (e.g. events or state information). Just like FTP servers. When a client disconnects, the server continues to serve the other clients. Just like FTP servers. A client can connect to multiple servers, uploading data and downloading data to all of them. Just like FTP clients. When the server shuts down, all clients are disconnected, but only from this server. Connections to other servers stay open and active. Just like FTP clients. (I'm sure I could come up with more, but ...) I repeat, X server and client notion are _not_ reversed. People seem get it wrong because back in the days of yonder, there was a big machine that was also referred to as The server and user's machines were referred to as the clients. And all the server processes like FTP, NFS, etc. were running on the server. All except X, where the user was running the server software and the server was running the clients. Hardware is not software, and this problem is little more than the English language using the same word for two different things. You don't even have to rethink what servers and clients are. You just simply ignore the hardware-specific definitions because quite frankly, they make little sense these days anyway. My laptop runs several server processes yet I would never think of it a server (in the hardware specific meaning). I wouldn't consider my phone to be the server either, even though it can run server software. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Touchscreens (mutouch) multiple heads
On Mon, Apr 18, 2011 at 09:19:07AM -0400, Michael Smith wrote: Peter Hutterer wrote: On Fri, Apr 15, 2011 at 12:11:09PM -0400, Michael Smith wrote: Hi, I have an Intel 915GM with two heads, each 800x600. One head feeds a touchscreen using the mutouch driver. Touchscreen input is being scaled by the total screen dimensions (1600x600), rather than just the 800x600 part of the display that is connected to the touchscreen. Where is the right place to add a way to override the screen width used for converting raw coordinates? Or is there already a way to do this? http://www.x.org/wiki/XInputCoordinateTransformationMatrixUsage run-time only though Thanks! I ended up doing something similar by fiddling with negative MinY/MaxY values. It's encouraging to know I'm not the only one with this use case (i.e. Wacom tablet users also solve the same problem). The transformation matrix may be a decent way to implement this internally, but as a user interface it's pretty awful - it would be nice to have a knob that says input device X is associated with the bounds of screen Y so you don't have to manually recalculate your matrix if you dynamically add or remove a screen or change a resolution. xsetwacom has such a knob with MapToOutput but long term something desktop-specific is needed (i.e. gnome, kde, etc.) Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.4.0.901
First and likely only RC for synaptics stable release 1.4.1. Main issues fixed: - x/y resolution assignment typo - workaround for syndaemon's CPU spike when RECORD sends an event down the data connection And a number of documentation updates, both man pages and the example configuration files. If you find any build errors or crashes with this, please file a bug now, otherwise I'll tag this as 1.4.1. Alexandr Shadchin (1): Fix typo (resx - resy) Chase Douglas (1): Drain XRecord connection of any events after handling replies Christoph Brill (1): Add note about MatchDevicePath Cyril Brulebois (1): Fix egde/edge typo in manpage and comments. Peter Hutterer (6): man: update source path for fdi file and shorten description. man: add short blurb about InputClass configuration in servers 1.8 conf: remove SHM example from fdi conf: add a descriptive header with warning to example config file eventcomm: add a missing break statement synaptics 1.4.0.901 git tag: xf86-input-synaptics-1.4.0.901 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.4.0.901.tar.bz2 MD5: 776d4905302c0a66dc284a79e81c9b4b xf86-input-synaptics-1.4.0.901.tar.bz2 SHA1: 2203f64a9d656088387c81c5914422c63827848f xf86-input-synaptics-1.4.0.901.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.4.0.901.tar.gz MD5: 3b898403a8282b55f53d2b3f649a44b6 xf86-input-synaptics-1.4.0.901.tar.gz SHA1: a904707e820b1a66a2c1844691da35eae937bb9a xf86-input-synaptics-1.4.0.901.tar.gz pgpEzBH3sZ5sN.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
