Re: Xsettings after keyboard is plugged
On Thu, Dec 29, 2011 at 06:51:37AM +0530, Raghavendra D Prabhu wrote: > Hi, > > When X is running and I plug out/plug in my usb keyboard, I see that > Xmodmap/xset etc settings get lost and I have it to run xmodmap/xset > again for them to apply to the keyboard. Is this a bug or the > behavior the way it should be ? intended behaviour, the post below has a bit more info: http://who-t.blogspot.com/2010/06/keyboard-configuration-its-complicated.html Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-keyboard 1.6.1
Main change: PC98 support was removed from the server. If you are planning to update to server 1.12, you will need to update to 1.6.1 Matthieu Herrb (1): man: update "rules" default value for xkeyboard-config. Peter Hutterer (3): Remove calls to xf86IsPc98() man: link to xkeyboard-config(7) (#14494) keyboard 1.6.1 Terry Lambert (1): Return proper default for unknown values in pInfo->device_control. git tag: xf86-input-keyboard-1.6.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-keyboard-1.6.1.tar.bz2 MD5: 09744e8dc9a1fe5e61927c1073cd3428 xf86-input-keyboard-1.6.1.tar.bz2 SHA1: ef30fecb9e846a5268ae339846401489a785e413 xf86-input-keyboard-1.6.1.tar.bz2 SHA256: aa9ec96e7f7f87bc086cb86b871ee6f4b9a7809fb1e7d50d0abbd7c2e50a8cc3 xf86-input-keyboard-1.6.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-keyboard-1.6.1.tar.gz MD5: c2188611990880f06f7d6c2a7672af1b xf86-input-keyboard-1.6.1.tar.gz SHA1: 695069472f69806b0583bcd7342c8f7f4df84736 xf86-input-keyboard-1.6.1.tar.gz SHA256: 601c27fd6073ad02c1013e23b2bd8ef4ad49b6d8f0965e66dde55328eee7b262 xf86-input-keyboard-1.6.1.tar.gz pgpIxQGlUL1Pi.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] inputproto 2.1.99.5
Another inputproto snapshot, with a number of spec clarifications. The main change here (that warrants the snapshot) is the addition of another flag to mark those touch events that also emulate pointer events. Peter Hutterer (5): specs: Clarify rejection for touch events on current owner specs: only pointer events have a PointerEmulated flag specs: purge leftover TouchAccepted note Set a flag on the pointer-emulating touch event inputproto 2.1.99.5 git tag: inputproto-2.1.99.5 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.5.tar.bz2 MD5: 6c71d07846407b9c82d8ec79e4d1cc67 inputproto-2.1.99.5.tar.bz2 SHA1: cfc5c69a47a7fe4eb1349c08d09c209087b1a9e3 inputproto-2.1.99.5.tar.bz2 SHA256: 4e095699f4ad8b11d6c1f77a136c1a10486ed355b678b14af55d66fa30d26af3 inputproto-2.1.99.5.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.5.tar.gz MD5: 4ba66ce3ee151f7041d4e6670522a74f inputproto-2.1.99.5.tar.gz SHA1: 1daeae72004069737e619d7666d45a8716768e4f inputproto-2.1.99.5.tar.gz SHA256: 60912085b28c8915531282efa2d55ec3b747de03b7f1e15cbb50bf866ace8db9 inputproto-2.1.99.5.tar.gz pgpuPE3KBskDX.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Re: Xsettings after keyboard is plugged
On Sat, Jan 14, 2012 at 04:11:25AM +0530, Raghavendra D Prabhu wrote: > Hi Peter, > > * On Tue, Jan 03, 2012 at 11:18:42AM +1000, Peter Hutterer > wrote: > >On Thu, Dec 29, 2011 at 06:51:37AM +0530, Raghavendra D Prabhu wrote: > >>Hi, > > >>When X is running and I plug out/plug in my usb keyboard, I see that > >>Xmodmap/xset etc settings get lost and I have it to run xmodmap/xset > >>again for them to apply to the keyboard. Is this a bug or the > >>behavior the way it should be ? > > > >intended behaviour, the post below has a bit more info: > >http://who-t.blogspot.com/2010/06/keyboard-configuration-its-complicated.html > > > >Cheers, > > Peter > > Thanks for the article, it is quite explanatory. I am manually > applying the configuration now -- xmodmap and xset ones. > > Quick question since the article touches on core keyboard -- I > notice this http://sprunge.us/Magg -- there are lot of stuff like my > headphone, Video Bus are under Virtual core keyboard. Is this normal > ? or is this because of some udev and/or IsKeyboard xorg bug ? that's normal. If it has keys, we'll treat it as a keyboard. Amongst other things, this should allow for things like your desktop environment picking up mute/camera/etc buttons. (the 255 keycode limit sometimes gets in the way here though, but the principle is there anyway) Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Recent linux kernel bug causing problem for xkbcomp
On Tue, Jan 24, 2012 at 03:33:36PM -0800, walt wrote: > Hi team. I'm trying to debug a recent commit to Linus's git repo > that causes startx to halt with a complaint that it can't write a > .xkm file to /var/lib/xkb. > > I'm assuming that the message is from xkbcomp, but I can't find > where in the startx process that xkbcomp is run, or what else might > produce such an error message. I'd like to reproduce the error by > running xkbcomp manually so I can track it down. the xserver calls it via popen(3) in XkbDDXCompileKeymapByNames, , see xserver/xkb/ddxLoad.c Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XExtension Device
On Thu, Jan 26, 2012 at 04:54:58PM +0100, Pascual Castellon Gadea wrote: > Dear all, > > I recently installed CentOS 6 in one on my computers. CentOS 6 comes > with X.Org X Server 1.10.4 as shown in the log file. > I noticed many changes with the previous version or xorg, but my > main problem now, is the Extension Devices configuration. > > I have a wacom tablet connected through port USB. The piece of > xorg.conf related is: > > Section "InputDevice" > Identifier "WACOM_TABLET" > Driver "wacom" > Option "Device" "/dev/input/wacom" > Option "USB" "on" > #Option "SendCoreEvents" "off" > Option "Floating" "on" > Option "Type" "Stylus" > Option "Mode" "Absolute" > EndSection > > I commented out the former 'SendCoreEvents' option since I read > somewhere this option was changed for 'Floating'. But even when > I set this option, and I see is recognized in the log file, as: > > [229352.620] (II) Using input driver 'wacom' for 'WACOM_TABLET' > [229352.620] (II) Loading /usr/lib/xorg/modules/input/wacom_drv.so > [229352.620] (**) Option "Floating" "on" > [229352.620] (**) WACOM_TABLET: doesn't report core events > [229352.620] (**) Option "Device" "/dev/input/wacom" > [229352.642] (EE) PreInit returned 8 for "WACOM_TABLET" > [229352.642] (II) UnloadModule: "wacom" > [229352.642] (II) Unloading wacom > > I noticed the line '(EE) PreInit returned 8 for "WACOM_TABLET"' > which might be the focus of the problem. > > How to configure my wacom tablet as an extension device? > How to make the preInit line error disappear? probably by fixing the driver, if PreInit returns 8 something has gone wrong with the driver and it could not initialise the device. Option CommonDBG or DebugLevel may provide you with more information here but it's best to file a bug with the details about your device. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [BUG] xinput bug in Xorg 1.12-rc2
On Thu, Feb 02, 2012 at 05:00:58PM +0100, Mathieu Taillefumier wrote: > On 01/31/2012 07:20 PM, Jeremy Huddleston wrote: > >That's pretty much an entire merge you are blaming now. Are you sure you > >can't narrow it down further than that? If you're having a build failure, > >just apply the fix at each step rather than doing a 'git skip' ... > > Sorry for the delay. The bisection was nightmarish because I had to > fix some include files to complete the compilation. Anyway this is > done now. The first bad commit where the bug appears is this one > > 6eff14a789341d366b3013c5aa020e959c954651 > dix: deduplicate callers of DeliverDeviceEvents in DeliverGrabbedEvents > > but since I do not know the code I can not give more informations > except the gdb session that you already have. I'm staring hard at this code but I can't spot an actual functional change here that could trigger a bug - just as the commit msg said this was just shuffling code around. are you sure it's that one? have you tried reverting it to see if the bug disappears? Cheers, Peter > > Mathieu > > Ps : I will modify the bug report with the new information. > > > > > > > >On Jan 31, 2012, at 6:05 AM, Mathieu Taillefumier wrote: > > > >>Hello, > >> > >>thank you for the answer. > >> > >>On 01/31/2012 12:28 AM, Jeremy Huddleston wrote: > >>>I really don't see how 2abe83df686ed64c4f4df711ac3c1fd12131c2e4 could be > >>>the culprit. It's trivial. > >>I made a mistake somewhere so to double check I did the bisection again > >>starting from 1.11.99.1 (working) to 1.11.99.2 (not working). > >> > >>The result is that I was unable to bisect the last three steps because of > >>compilation errors (that are fixed later on). You can find the last patchs > >>that caused the compilation issue enclosed to the email (bisect.result). > >>The result from the bisection are in the git.log file. > >> > >>>Can you please create a bug report at http://bugs.freedesktop.org to track > >>>this? > >>I will do that. > >> > >>Mathieu > >>> > >>>On Jan 30, 2012, at 4:59 AM, mathieu.taillefum...@free.fr wrote: > >>> > Hello, > > i encounter a bug in the last rc of the xserver (present before but I > was using it so far) when I use it in combination with kdm (and only > kdm, I did not try xdm). The server simply crash when kdm is running and > I touch any of the keyboard keys but works perfectly fine when I run it > from a console. The all stack is from the git repository but the problem > originates from the server itself since I can not reproduce it with xorg > 1.11.4 for instance (with the same stack almost). > > I am able to reproduce it all the time and I have been spending some > time to bisect the problem (changing the server, the rest been fixed). > The result of the bisection gave me this: > > git bisect start > # bad: [052ca3f22eadd0aa60dd24ac7d5d76137273926f] Bump version to > 1.11.99.902 (1.12 RC2) > git bisect bad 052ca3f22eadd0aa60dd24ac7d5d76137273926f > # good: [e597f0119cd69b6d9edf86d06d941468f90d8e6d] configure.ac: 1.11.4 > git bisect good e597f0119cd69b6d9edf86d06d941468f90d8e6d > # good: [4ad271d06c5aa42721c0e2e01e17e34a39825c65] xfree86: Bump > extension ABI version to 6.0 > git bisect good 4ad271d06c5aa42721c0e2e01e17e34a39825c65 > # good: [34b0e4eee911f8b09a3682a7f1b4c8598ef48b8d] dri2: Register the > DRI2DrawableType after server regeneration > git bisect good 34b0e4eee911f8b09a3682a7f1b4c8598ef48b8d > # bad: [2df539c0bc3300ea858f8bc7d52e95e67ff379b8] glx: Only declare > GlxExtensionInit in one header file > git bisect bad 2df539c0bc3300ea858f8bc7d52e95e67ff379b8 > # bad: [2abe83df686ed64c4f4df711ac3c1fd12131c2e4] include: add > BUG_WARN_MSG for custom error message on bug condition > git bisect bad 2abe83df686ed64c4f4df711ac3c1fd12131c2e4 > # good: [d26fae246d7c451b4d5ffe24fdb959d4bd00b107] glx: don't leak > fbconfigs > git bisect good d26fae246d7c451b4d5ffe24fdb959d4bd00b107 > # good: [6acebf9e1298939593b942ec91ae9ec9e74faa19] include: add > list_append() > git bisect good 6acebf9e1298939593b942ec91ae9ec9e74faa19 > # good: [4bc2761ad5ec2d0668aec639780ffb136605fbc8] dix: switch the > dev->deviceGrab.activeGrab from GrabRec to GrabPtr > git bisect good 4bc2761ad5ec2d0668aec639780ffb136605fbc8 > # good: [d2ebbcdaf6b13d70eee704b1764ff349e1be22a0] Xi: when removing a > device, reset ClientPointers where needed > git bisect good d2ebbcdaf6b13d70eee704b1764ff349e1be22a0 > # good: [631516a4aa9858874ee197444cd93d91b97a1089] Xi: check button > mapping value _before_ assigning it > git bisect good 631516a4aa9858874ee197444cd93d91b97a1089 > # good: [4fc797f3756611a97767f407e1af0b6a7cf2f1d9] xfree86: include > xorg-config.h from xaalocal.h > git bisect good 4fc797f3756611a97767f407e1af0b6a7cf2f1d9 > > so the first bad commit is 2abe8
Re: [BUG] xinput bug in Xorg 1.12-rc2
On Fri, Feb 03, 2012 at 04:01:21PM +0100, mathieu.taillefum...@free.fr wrote: > I think I found where the error is. the original code (before the patch) > contains a very last "if" before the third possible call to > DeliverDeviceEvents which is if(focus) then call the function. After > debugging it again with gdb i found that (with the patch included) the > variable focus is null (it is due to this line focus = > thisDev->focus->win;) and win is not initialized at all and has random > values. That is why I have a segmentation fault. To check that win was not > initialized when i triggered the bug i just put its value to null at this > line WindowPtr win = null. then I trigger the bug and check the value of > win which is null as espected from the previous debugging session. > > So the bug has to components : > - the win variable which in some cases is not initialized (it arrives when > we run focus = thisDev->focus->win; and thisDev->focus->win == null) > - focus is null (thisDev->focus->win is zero in my case). > > It did not happen before because the function DeliverDeviceEvents could > only be called when focus has a non zero value. To fix this bug, two lines > should be modified > > - WindowPtr win -> WindowPtr win = null (by the way the compiler did not > seem to complain) > - DeliverDeviceEvents() -> if(win) DeliverDeviceEvents > > I also check the function DeliverDeviceEvents and it seems that the > "if(win)" is not necessary since it is a loop over the win parameter. thanks, you're right, this is a bug. I've just sent out the patch reverting the commit - since it was supposed to only clean up code but not include any functional changes, this is the simpler way than trying to fix a patch that's just cosmetic anyway. thanks for the debugging, much appreciated! Cheers, Peter > > regards > > Mathieu > > > - Mail original - > De: "Peter Hutterer" > À: "Mathieu Taillefumier" > Cc: "Jeremy Huddleston" , xorg@lists.x.org, "Keith > Packard" > Envoyé: Jeudi 2 Février 2012 18:43:27 > Objet: Re: [BUG] xinput bug in Xorg 1.12-rc2 > > On Thu, Feb 02, 2012 at 05:00:58PM +0100, Mathieu Taillefumier wrote: > > On 01/31/2012 07:20 PM, Jeremy Huddleston wrote: > > >That's pretty much an entire merge you are blaming now. Are you sure you > > >can't narrow it down further than that? If you're having a build failure, > > >just apply the fix at each step rather than doing a 'git skip' ... > > > > Sorry for the delay. The bisection was nightmarish because I had to > > fix some include files to complete the compilation. Anyway this is > > done now. The first bad commit where the bug appears is this one > > > > 6eff14a789341d366b3013c5aa020e959c954651 > > dix: deduplicate callers of DeliverDeviceEvents in DeliverGrabbedEvents > > > > but since I do not know the code I can not give more informations > > except the gdb session that you already have. > > I'm staring hard at this code but I can't spot an actual functional change > here that could trigger a bug - just as the commit msg said this was just > shuffling code around. > are you sure it's that one? have you tried reverting it to see if the bug > disappears? > > Cheers, > Peter > > > > > Mathieu > > > > Ps : I will modify the bug report with the new information. > > > > > > > > > > > > >On Jan 31, 2012, at 6:05 AM, Mathieu Taillefumier wrote: > > > > > >>Hello, > > >> > > >>thank you for the answer. > > >> > > >>On 01/31/2012 12:28 AM, Jeremy Huddleston wrote: > > >>>I really don't see how 2abe83df686ed64c4f4df711ac3c1fd12131c2e4 could be > > >>>the culprit. It's trivial. > > >>I made a mistake somewhere so to double check I did the bisection again > > >>starting from 1.11.99.1 (working) to 1.11.99.2 (not working). > > >> > > >>The result is that I was unable to bisect the last three steps because of > > >>compilation errors (that are fixed later on). You can find the last > > >>patchs that caused the compilation issue enclosed to the email > > >>(bisect.result). The result from the bisection are in the git.log file. > > >> > > >>>Can you please create a bug report at http://bugs.freedesktop.org to > > >>>track this? > > >>I will do that. > > >> > > >>Mathieu > > >>> > > &g
Re: [BUG] xinput bug in Xorg 1.12-rc2
On Sat, Feb 04, 2012 at 11:11:55AM +0100, Mathieu Taillefumier wrote: > > >thanks, you're right, this is a bug. I've just sent out the patch reverting > >the commit - since it was supposed to only clean up code but not include any > >functional changes, this is the simpler way than trying to fix a patch > >that's just cosmetic anyway. > > Yes but the initial idea is good and the fix is straightforward so > why not keeping it and send a patch of one line (or two if we want > to keep the last if check) initializing the win variable to null. In > that case, the function behaves as before the troublesome patch and > the reading is simplified by some small rewriting. So all in all the > original code is actually very good and fixing the mistake is > simple. This is not important anyway it was just a kind suggestion. feel free to rewrite the reverted patch with those fixes, it's one of the cases where it's just easier right now to revert it (i'm also currently travelling and testing is hard). plus, that way we have the patch in one, not across two patches that may make future cherry-picking harder. > Ps : the bug report should be marked as closed. will do once it's on master. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xinput 1.5.99.1
A new release for xinput with the main changes being support for scrolling axes and for multitouch devices. Plenty of cleanups and misc fixes, but also a few new behaviours: - xinput without any arguments will now assume "xinput list" - xinput --name-only will print the device name only - xinput --id-only will print the device ID only - xinput map-to-crtc will set an absolute device's transformation matrix to the respective CRTC dimensions Alan Coopersmith (1): print_version expects no arguments, so give it none Bryce Harrington (1): xinput: Assume 'list' by default if no args given. Chase Douglas (2): Print XI2 device event child window in hex too Zero out entire mask when selecting for different events David Fries (1): Fix typo in man page for the --test-xi2 option. Gaetan Nadon (14): config: update AC_PREREQ statement to 2.60 config: upgrade to util-macros 1.8 for additional man page support config: use AC_PROG_SED now supplied by XORG_DEFAULT_OPTIONS config: use AC_PROG_INSTALL now supplied by XORG_DEFAULT_OPTIONS config: remove AC_PROG_CC as it overrides AC_PROG_C_C99 config: remove unrequired AC_SUBST([*_CFLAGS]) config: remove unrequired AC_SUBST([*_LIBS]) config: replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS man: replace hard coded section number with __appmansuffix__ Use the value of MAN_SUBSTS from util-macros for man pages Man pages Makefile: fix whitespace Remove redundant definition of the VERSION Automake variable Apply standard configuration init, layout and comments Update Copyright notices. Jeremy Huddleston (1): Print usage when run with --help Peter Hutterer (26): Remove unneeded include. Switch list to use an enum of printing formats. Add --name-only flag for 'xinput list'. Add --id-only flag for 'xinput list'. Fix broken "xinput list ". Silence compiler warning Initialize a few more values to defaults. Announce support for XI 2.0 to the server. Remove superfluous comment. man: update missing copyrights man: Move my name to the top of the authors list Add support for device-to-screen mapping list: don't use defines for checking server version. test-xi2: print the correct flags, depending on the event type Print the class type when listing devices. test-xi2: support a device option Enclose button labels with quotes to improve readability Only try to print XIPointerEmulated flag if it is defined. Support the new Scroll class list: drop XIQueryVersion call We support XI 2.1 now test-xi2: Use the longest mask we can get test-xi2: add basic touch support test-xi2: check return value of list, exit on failure add support for touch raw events xinput 1.5.99.1 git tag: xinput-1.5.99.1 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.99.1.tar.bz2 MD5: e1a9f7b014694dd3354b1b72daa247f4 xinput-1.5.99.1.tar.bz2 SHA1: f979d9a4005d71db7e58064dff6ca6738bd9a345 xinput-1.5.99.1.tar.bz2 SHA256: 4e465634a04119f4b89fe779a84b6105bd3d7d5fd1ec675bd6cfc35bf387b951 xinput-1.5.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.99.1.tar.gz MD5: 0025510f8260c143ac109be5e40152f4 xinput-1.5.99.1.tar.gz SHA1: 19d502abd35997b384f6a8bfe3ddf4c2c89ab1fb xinput-1.5.99.1.tar.gz SHA256: 1012c13ccfac4f3fdd28f704ef7c443beaa089903976d089d987068a0aa25faf xinput-1.5.99.1.tar.gz pgprijGfqBl93.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] inputproto 2.1.99.6
This version of the protocol brings one major change: the changes to the XIAllowEvents request broke the ABI and triggered BadLength errors if the library compiled against the new headers ran against a server compiled against the old headers. We have now split out a second struct for the modified XI 2.2 request. Aside from that, spec document cleanups and some more explanations. Gaetan Nadon (5): specs: Edit titles for section 3 and 4 specs: use subsections to group use cases description specs: remove older manually typed in section number specs: fix Appendix A title specs: replace hard coded number in some "See section" references Peter Hutterer (5): specs: move touch mode explanations to where it belongs specs: remove superfluous "Changes introduced by ..." specs: move touch support details to "Touch device support" section specs: explain touch behaviour for dependent devices Unbreak protocol ABI for XIAllowEvents - inputproto 2.1.99.6 git tag: inputproto-2.1.99.6 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.6.tar.bz2 MD5: f131c9b60d4fff33ae4a44e4813e13d6 inputproto-2.1.99.6.tar.bz2 SHA1: 36d5ff554c9edc6eb116f3f08d32cd2acd75e9b5 inputproto-2.1.99.6.tar.bz2 SHA256: 88f8206bd7f181df4b83510fbfd85400a48a16b081d1d6bb97d5cba880aa5da1 inputproto-2.1.99.6.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.6.tar.gz MD5: 617ce296c90d451d6025e60e66bc4a1d inputproto-2.1.99.6.tar.gz SHA1: aee017077953a16ccf91f96f5e80436ba83f7e30 inputproto-2.1.99.6.tar.gz SHA256: 31a0f4da41b4320152cded50b24cc16f7951f40525eb053371059ef579ee5857 inputproto-2.1.99.6.tar.gz pgp5xDBqVusQk.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libXi 1.5.99.3
This version now handles the new XIAllowEvents request size. One bugfix: XIQueryDevice()'s class alignment was changed to line up with sizeof(XID) to avoid a SIGBUS on some platforms where XID is 8 bytes. Cyril Brulebois (1): configure.ac: Fix a typo in comments. Peter Hutterer (4): man: fix typo Mappiing → Mapping Force class alignment to a multiple of sizeof(XID). Handle new XIAllowEvent request size libXi 1.5.99.3 git tag: libXi-1.5.99.3 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.99.3.tar.bz2 MD5: b2b7685a238806375a45f7684cfda813 libXi-1.5.99.3.tar.bz2 SHA1: 55de70d18b20341f307b80da035400ed0467c920 libXi-1.5.99.3.tar.bz2 SHA256: f065b0bfd55cb1854ab8a5b94c168b37d69d5535ab8ca228d1902b9d72b0cefb libXi-1.5.99.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.99.3.tar.gz MD5: 2b366f3935baa4de0f522e2b766dcbd6 libXi-1.5.99.3.tar.gz SHA1: 7501c71b597ec7187b5c74d78ceb4e3abfe18de1 libXi-1.5.99.3.tar.gz SHA256: f321383f6361477fb52630247ff4b8054f53a6ca3db64c55d0d0f36ef86f1729 libXi-1.5.99.3.tar.gz pgp3Z9dgyvzhA.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] inputproto 2.2
The X Input Extension protocol version 2.2 is now available. The main feature added in this version is support for multitouch devices and the ability for clients to register for and receive touch events. Multitouch support in XI 2.2 aims to - support a dynamic number of simultaneous touch points, - support devices that are both multitouch and traditional pointer devices, - allow touchpoints to be either grouped together or handled separately, - be backwards-compatible to pre-XI 2.2 clients through emulation of XI 2.x/XI 1.x and core pointer events. For a description of the new features see the following posts: - http://who-t.blogspot.com.au/2011/12/multitouch-in-x-getting-events.html - http://who-t.blogspot.com.au/2011/12/multitouch-in-x-pointer-emulation.html - http://who-t.blogspot.com.au/2012/01/multitouch-in-x-touch-grab-handling.html - http://who-t.blogspot.com.au/2012/02/multitouch-in-x-multitouch-touchpads.html Many thanks to all who have contributed to this protocol. As usual, the full changelog since 2.1 is below. Chase Douglas (28): Updates for pointer emulation and more touch device modes Many more updates to the XI 2.1 protocol Separate "XI2.x" into "XI 2.x" for readability Yes, send TouchEnd to owner, TouchPendingEnd to other listeners Update device type terminology Prettyify touch device types Peter is right, floating devices can emit touch events Fix up pointer event emulation section Remove touch "Observe" grabs Use the same valuator axes for pointer and touch events Specify dependent device pointer/touch handling Introduce Touch grab mode Fix indentation of active_touches definition Fix touch cancel/resume semantics Revert "Fix touch cancel/resume semantics" Revert "Specify dependent device pointer/touch handling" Switch multitouch additions to XI 2.2 Bump version to 2.1.99 for XI 2.2 multitouch changes Really kill touch valuators Add event windows to ownership events Extend XIAllowEvents for handling touch grab processing Allow grabbing clients to accept or reject touches any time inputproto 2.1.99.1 (first snapshot of 2.2) Fix Xi 2.x version comment in XI2.h Revert addition of active_touches to device events Touch IDs must be globally unique State that future touch IDs are indeterminate inputproto 2.1.99.3 Cyril Brulebois (1): specs: Fix tiny typo. Daniel Stone (11): Add touch classes and events, bump to 2.1 Require configure flag to build this proto version. Formatting fixups and minor rewording Doc note: No seriously, this is WIP Add inline references, fix usecase bulleting Add FIXME sidebars, remove single-grab stipulation typo fix Reword touch introduction, labels for all Further cleanups and clarifications Mostly typographical Clean up and reword multitouch ownership/emulation Gaetan Nadon (5): specs: Edit titles for section 3 and 4 specs: use subsections to group use cases description specs: remove older manually typed in section number specs: fix Appendix A title specs: replace hard coded number in some "See section" references Peter Hutterer (67): specs: add a linebreak for asciidoc parsing specs: move from "init move destroy" to "begin update end" specs: move touch sequence handling (owner-only) up a bit. specs: move warning about out-of-band processing up a bit. spec: Move ClientPointer up again. specs: clean/rewrite touch grab and ownership bits specs: Add a fixme for using raw events instead of GrabModeObserve specs: Rewrite Touch events delivery section specs: rewrite pointer emulation for indirect devices specs: rewrite pointer emulation section Put a #warning and #error in to avoid unsuspecting XI 2.1 users. XITouchClass' props needs a num_props Changing the touch device mode generates a DeviceChangedEvent Add two linebreaks for asciidoc list parsing Coordinates are always absolute, no need to re-state it XISelectEvents: BadValue is generated, not returned Fix missing 'and' in GrabTypeFocusIn description Reword the passive touch grab rules to be similar to the others Indent Ownership explanation for consistent formatting AllowTouchEvents can take any device id, not just slaves DeviceEvent: active_touches needs marker that it's XI 2.1 DeviceEvents: a TouchPendingEnd won't generate further TouchUpdate events specs: Fix in-document references specs: Fix event lists for asciidoc parsing Change file header to note version 2.x Add comment to XI2.h to mark where the 2.1 events start specs: extend XI2.1 raw events to include touch events
[ANNOUNCE] xf86-input-evdev 2.7.0
evdev 2.7 is now available. Changelog below is for all the patches since 2.6, it was quite a big development cycle. Notable additions in this version are support for smooth scrolling in XI 2.1 and multitouch support for XI 2.2. Note that for multitouch support, evdev requires mtdev. This is a new dependency. Chase Douglas (12): Remove support for X input ABI < 12.2 Switch to "goto" logic for error handling when adding classes Add support for masked valuators Ensure events are posted when entering into proximity Ensure all known valuator values are stored when out of proximity Copy out of proximity values into current values selectively Add experimental XI 2.1 multitouch support Use MTDev for multitouch devices Ensure touchpad events are always processed with MT Don't send pointer events for multitouch touchscreen devices Set the default resolution to 0 Copy last valuator values into new touch valuator masks Cyril Brulebois (2): evdev 2.6.99.901 configure.ac: Fix udev/libudev dependency. Daniel Kurtz (1): Set prop_product_id undeletable Jeremy Huddleston (1): Remove redundant redeclaration of Evdev3BEmuPreInit Jools Wills (1): emuThird: Use xf86SetIntOption, not xf86SetBoolOption for integer values Max Schwarz (1): type-safe inline functions for bitmask manipulation Paulo Zanoni (2): Fix absolute events with swapped axes Fix relative events with swapped axes Pete Beardmore (1): missing multitouch related define tests Peter Hutterer (43): Replace xf86Msg() with xf86IDrvMsg(). Static atoms don't need to be initialized to 0. Add third button emulation. Use Absolute/Relative as argument to xf86Post* Move invert variable to the block it is used in. Export product/vendor ID through a property. Add a property to toggle function key mode Export device node as property. Require server 1.10 Print abs axes ranges on verbosity 6. Remove unused misc_label and val Exit axis labelling if axes are neither rel nor abs Don't crop long value from EvdevBitIsSet. Support smooth scrolling on REL_WHEEL, REL_HWHEEL and REL_DIAL Bump to 2.6.99 Move misplaced #endif caused by smooth-scrolling merge Use a new "Virtual Device" boolean property to mark virtual devices Remove duplicate line Use mtdev API to allocate/free mtdev structs 0 is the value for "unknown/unlimited" number of touches MT axes are counted separately, make sure they're initialized too. When resetting the queue, don't reset the touchMask Simplify a condition, only the event type differs here Replace open_slot/close_slot with a SlotState enum Skip event posting for empty slots. Replace 0/1 button values with enums Print to the log if we find multitouch axes. Add the required defines to compile against the inputproto Use xf86InitValuatorAxisStruct, the touch-specific version was dropped Map ABS_MT_POSITION_X/Y into ABS_X/Y Drop now-unnecessary XI 2.1 and XI 2.2 error suppression defines Add is_blacklisted_axis() helper Don't count legacy and MT axes twice Always include mt_mask in the evdev struct Include config.h from evdev.h Remove need for --enable-multitouch Test for mtdev before assuming multitouch Require xserver 1.12 RC1 Remove unused udev.c Force x/y axes to exist on devices with any other axes (#44655) Prefere relative axis labelling over absolute axis labelling Only force REL_X/Y if no ABS_X/Y exists evdev 2.7.0 Peter Korsgaard (1): Handle touchscreens without BTN_TOUCH Rami Ylimäki (3): Release leaked XKB options on input device disconnect. Release leaked device identifier on input device disconnect. Remove constness of device filename to avoid warning when freed. Simon Thum (1): rename valuator init functions Terry Lambert (1): xf86-input-evdev: Return proper default for unknown values in pInfo->device_control. git tag: xf86-input-evdev-2.7.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.7.0.tar.bz2 MD5: 4449b2e94900e98d2f41c2f46dd0397e xf86-input-evdev-2.7.0.tar.bz2 SHA1: f0cb2d8400c33e8e83b538b53512e77ba73367fa xf86-input-evdev-2.7.0.tar.bz2 SHA256: 3ee1feee0ccf748005ca30b0993d0c1b80f85158b726745f9e0cb220902d6ec7 xf86-input-evdev-2.7.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.7.0.tar.gz MD5: 2d3f7111b8284cec81884023c4bb4a11 xf86-input-evdev-2.7.0.tar.gz SHA1: 7989e540c7ae1f8b5ad2fb358b03eebf7db975e0 xf86-input-evdev-2.7.0.tar.gz SHA256: cf4bdbd4b40f05d4e29cd6494c64f092667202b0834c54bdaed448463622807b xf86-input-evdev-2.7.0.tar.gz pgp3Ku6m9pKVx.pgp Description: PGP signature _
[ANNOUNCE] libXi 1.6.0
The main fix that libXi 1.6 brings is support for XI 2.2 multitouch events and the matching protocol changes. Chase Douglas (1): Fix XIScrollClass increment value on 32-bit machines Cyril Brulebois (1): configure.ac: Fix a typo in comments. Michał Masłowski (1): Fix bus error on MIPS N32 for bug #38331. Peter Hutterer (8): Bump to 1.5.99.1 Implement support for XI 2.2 libXi 1.5.99.2 man: fix typo Mappiing → Mapping Force class alignment to a multiple of sizeof(XID). Handle new XIAllowEvent request size libXi 1.5.99.3 libXi 1.6.0 git tag: libXi-1.6.0 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.6.0.tar.bz2 MD5: 2e7f84711035e672c34549eac5660a0f libXi-1.6.0.tar.bz2 SHA1: b7edf48f93e8abd13ca688fa7f597452c4b74346 libXi-1.6.0.tar.bz2 SHA256: b2fc65a24a269405c5bbe27152e97ed4c5987ca728b9d7e7576e4c9543c4a7af libXi-1.6.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.6.0.tar.gz MD5: b28b32bca36bee899b6109d395de6ee6 libXi-1.6.0.tar.gz SHA1: f24ca140ba28958ffbbc622d85602c46de95093f libXi-1.6.0.tar.gz SHA256: c05ef216c6e4f3ccef73a06dcf1f5345e11ba384baab8543a7f520041bdc8907 libXi-1.6.0.tar.gz pgpIOLntUyUlD.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.12.0
On Thu, Mar 08, 2012 at 01:04:40PM -0500, Adam Jackson wrote: > On Wed, 2012-03-07 at 13:35 -0700, Jonathan Corbet wrote: > > Hey, Keith, > > > > A question: > > > > > Here's the final 1.12 release. Thanks to every for contributing new > > > features, > > > bug fixes, documentation and testing. > > > > Is there anything resembling release notes or a feature list for releases > > like this? It would be a lot easier for us to call them out if such a > > thing were available... > > There really should be, shouldn't there. > > Notable changes since 1.11.0, in my opinion, from a quick glance over > the git log: > > * udev/systemd-based multiseat support (things like Plugable USB gadgets > Just Work) > * DRI2 enhancements for low memory and better triple-buffering > * Better smooth scrolling (internally using doubles, etc) technically we've been using doubles/floats internally before, just in a rather weird way. The visible smooth scrolling change is XI 2.1 support for smooth scrolling events, so clients now get valuator information instead/in addition to button click events for scroll data. Cheers, Peter > * Driver support for RANDR rotation (instead of requiring a shadow > buffer) > * Multitouch support (XI 2.2) ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.5.99.901
This is the first RC for synaptics 1.6. I expect the release to happen quite
soon, though I still need to trawl through the bugzilla for dealbreakers.
Below is the full changelog, the most notable features are the addition of
multitouch support and support for ClickPads. ClickPads are touchpads that
don't have physical buttons but instead the touchpad itself works as a
button (or two, in some cases).
These ClickPads have a new property for the configuration of software
buttons, see the man page for more details.
When building with MT support enabled, mtdev is required.
Alexandr Shadchin (2):
On/Off hooks to return boolean so we can bail out of the caller
The correct maximum values for pressure and finger width
Benjamin Otte (1):
eventcomm: Fix initialization code
Casper Dik (1):
Extra buttons on Acer Ferrari 4000 laptop touchpad are not recognized
Chase Douglas (35):
Allocate axis labels array dynamically
Add touch device class support
eventcomm: Initialize touch device and axes
eventcomm: Read evdev events from mtdev where multitouch is available
eventcomm: Add touch event handling
Ensure delta computation does not go crazy
Only move the cursor when one touch is on a touchpad
Don't emit touch sequences if only one touch is active
Don't initialize touch state if device does is not multitouch
Don't initialize semi-multitouch devices for touch device class
Revert "Replace the motion estimator"
Allocate proto data in eventcomm-test
Introduce SynapticsHwStateAlloc() and SynapticsHwStateFree()
Transition eventcomm-test to new SynapticsHwState instantiation scheme
Allocate SynapticsHwStruct for local function use
Allocate SynapticsPrivate.comm->hwState
Allocate priv->hwState
Introduce SynapticsCopyHwState function
Rename num_touches to max_touches
Add touch valuator mask to hw state structure
Add open_slots array to SynapticsPrivate
Move X touch event processing into synaptics.c
Filter touch events if click actions are enabled
Filter touch events if tap actions are enabled
Filter touch events if two-finger scrolling is enabled
Prefer multitouch over single-touch axis ranges
Update touch state when device is off too
Don't use linear regression when calculating touchpad motion deltas
Add clickpad device property
Add cumulative_d{x,y} to SynapticsHwState
Enable clickpad click and drag with two fingers
Disable scrolling when beginning a clickpad press
Calculate touch data for semi-mt devices, but don't send touch events
Add soft button areas property
Ignore motion during touch count changes on semi-mt devices
Cyril Brulebois (1):
Revert: "eventcomm: replace synaptics-custom TEST_BIT with server's
BitIsOn."
Daniel Stone (17):
Shuffle include order around
Bump minimum xorg-server requirement to 1.7
Properties: Generalise InitTypedAtom from InitAtom
Add HIST_DELTA macro for differences in history
Give FingerState enums explicit values
Introduce POLL_MS for packet frequency
Use CARD32 for timestamps
Don't store fake events in the motion history
Update count_packet_finger in store_history, not get_delta
Scroll: Clarify rep_buttons assignment
Scroll: Move scroll_[xya] into new priv->scroll struct
Scroll: Move coasting variables to priv->scroll
Scroll: Modify ScrollData in repeat_scrollbuttons
Adjust acceleration scheme for input ABI v14
Scroll: Prepare ScrollData for smooth scrolling
Scroll: Initial smooth scrolling support
Constify priv->device
Derek Foreman (6):
Fix pressure->motion property format
Use hardware time where possible
Replace the motion estimator
More accurate extrapolated fake motion events
Revise palm check logic
Scroll: Add last_millis to track scroll event timing
JJ Ding (1):
fix wrong finger width range
Peter Hutterer (35):
Bump to 1.5.99
Fix compiler warning: unused variable "wakupTime"
man: note that a PS/2 device is not supported
test: wrap ABI 14 xf86OptionRec type changes
Fix compiler warning - unused variable 'para'
eventcomm: print strerror(errno), not of rc
Use the scroll distances as increment for scrolling valuator axes
Return true/false from SetDeviceAndProtocol
If protocol is auto-dev and the device path is set, unset the protocol
test: fix build errors introduced by upstream server change
Remove unused variable 'thr'
test: fix build error introduced in 9f9b55ab55ed5
synclient: fix indentation of "format mismatch" parameters
Remove compiler warning: unused variable "atom"
Submit the
Re: Mouse buttons/scroll directions swapped with recent Xorg
On Mon, Mar 12, 2012 at 01:48:03PM +0100, Thomas Bächler wrote: > Hello, > > Recently (beginning of February), I performed the following upgrades: > > xf86-input-evdev (2.6.0-4 -> 2.6.99.901-1) > xf86-input-synaptics (1.5.0-1 -> 1.5.99-0.1) > xorg-server (1.11.4-1 -> 1.11.99.903-1) > xorg-xinput (1.5.3-2 -> 1.5.99.1-1) > (Some of these packages have since been updated to their latest releases > or newer snapshots, but the problems I describe below remain the same.) > > Since then, I have two problems: > > 1) On my ALPS touchpad, the circular scroll direction has been reversed: > Scrolling left is now button 5, scrolling right is button 4. (The right > edge of the touchpad still scrolls correctly, up is button 4, down is > button 5.) definitely a regression, patch available here http://patchwork.freedesktop.org/patch/9512/ > 2) On my Logitech M555b mouse, buttons 6 and 7 have been swapped. Physical buttons or logical (scroll) buttons? If the former, please file a bug against evtest and attach a utouch-evemu recording of the button events. see http://people.freedesktop.org/~whot/evemu/ Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.5.1
This is just a stopgap release until synaptics 1.6 is ready (very soon). The 1.5.0 release's tests do not build against the 1.12 server due to some API changes. This release includes the necessary cherry-picks to make the driver build again (#47498). Also included are three patches that have been languishing on the branch for too long. One fixing a ppc regression when checking for event bits, one fixing the pressuremotion property format and one fix to unset the protocol if auto-dev is the chosen device to avoid issues with devices not found if both Protocol and Device "auto-dev" are in the xorg.conf Cyril Brulebois (1): Revert: "eventcomm: replace synaptics-custom TEST_BIT with server's BitIsOn." Derek Foreman (1): Fix pressure->motion property format Peter Hutterer (5): If protocol is auto-dev and the device path is set, unset the protocol test: wrap ABI 14 xf86OptionRec type changes test: fix build errors introduced by upstream server change test: fix build error introduced in 9f9b55ab55ed5 synaptics 1.5.1 git tag: xf86-input-synaptics-1.5.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.1.tar.bz2 MD5: 964a7faf52aa50d91f246a3785798a97 xf86-input-synaptics-1.5.1.tar.bz2 SHA1: f6140cdc11adf9c4f2bb1170974d23ec22839214 xf86-input-synaptics-1.5.1.tar.bz2 SHA256: 942fe65f5a96bc2f574303e369ab4032e3b4b7010a708c7ebb5a4b335530 xf86-input-synaptics-1.5.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.1.tar.gz MD5: 7d5ecdd5c7cf6c1813b85c207477a864 xf86-input-synaptics-1.5.1.tar.gz SHA1: 1a1b54bb53d2c4b39d89012dc61a71c4dd3f32c0 xf86-input-synaptics-1.5.1.tar.gz SHA256: 689764d0dbbbd5f82132fcdd4c7b8c4e2bc49ff174749565bc4b059ecf65572a xf86-input-synaptics-1.5.1.tar.gz pgpprxvFFqMH1.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.5.99.902
Second RC for synaptics 1.6. Chase fixed some of the issues with clickfingers on non-clickpads, so they should work again now. The softbutton areas are now enabled by default on clickpads, with the bottom right defaulting to a right button (except on Apples where right clicks remain too complicated for the average user). Chase Douglas (4): Fix clickfinger actions when middle button emulation is enabled Fix clickfinger actions when buttons other than 1 are reported Keep track of which touch slots are open Include open but unchanged touches when guessing clickfingers Peter Hutterer (5): Fix inverted circular scrolling direction Allow soft button areas to be specified in % of the touchpad use xf86SetStrOption for SoftButtonAreas conf: enable right-button click by default on non-Apple clickpads synaptics 1.5.99.902 git tag: xf86-input-synaptics-1.5.99.902 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.99.902.tar.bz2 MD5: 3e57a18839aad7e8633e19afdabd6b49 xf86-input-synaptics-1.5.99.902.tar.bz2 SHA1: 2170854823caf39f15f47329514fdbe620e31e96 xf86-input-synaptics-1.5.99.902.tar.bz2 SHA256: 6c03f912698cf85bf44463d2a33dbde2f15e3db7a04ff444c33c9a7ae58de36b xf86-input-synaptics-1.5.99.902.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.99.902.tar.gz MD5: aefa1ad0f904d50bbda24257773f6fde xf86-input-synaptics-1.5.99.902.tar.gz SHA1: 941c824d6863f092a11927e369c91d57a270bc98 xf86-input-synaptics-1.5.99.902.tar.gz SHA256: e56c5106d4968d1ca8ffa699a7cc32696258a37b9a89b715e7dc4c23aa585abe xf86-input-synaptics-1.5.99.902.tar.gz pgpFH7zfJ4by6.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Problems with xf86-input-synaptics 1.5.99.901
On Thu, Mar 22, 2012 at 12:55:02AM +0400, Ilya Ilembitov wrote: > Hi, all. > > I have HP Envy 13 which uses a single button design of Synaptics Clickpad. > > Using Arch Linux I have updated to xf86-input-synaptics 1.5.99.901 > which is supposed to bring proper support for my touchpad. > > What works: > -drag and drop > -two-finger scrolling > -tap to click, double tap to click for right button > > What doesn't work: > -right click > -button areas recognize movements, so the cursor jumps a lot during > drag and drop > > What can I do to fix the issues? is the touchpad recognised as clickpad? Try setting Option Clickpad on in a config snippet. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.5.2
Two cherry-picks from the master branch to fix two severe issues with the 1.5.1 branch. The first one fixes an unresolved symbol, the second one a pointer jump. For detailed bugreports refer to https://bugs.freedesktop.org/show_bug.cgi?id=47654 https://bugs.freedesktop.org/show_bug.cgi?id=47770 Daniel Stone (2): Properties: Generalise InitTypedAtom from InitAtom Adjust acceleration scheme for input ABI v14 Peter Hutterer (1): synaptics 1.5.2 git tag: xf86-input-synaptics-1.5.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.2.tar.bz2 MD5: f064477ef3a553634f3dcf6696d0f538 xf86-input-synaptics-1.5.2.tar.bz2 SHA1: ce93cfa218c2c7bce7881ac2dd2160e583eb4c4f xf86-input-synaptics-1.5.2.tar.bz2 SHA256: ac6f6efad8ddf85fa6c5d68cac0c452bcea91aa53d5ee10b6205a353dfffaa92 xf86-input-synaptics-1.5.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.2.tar.gz MD5: 6f2fe3863366fa9b2575e460f57c4e7c xf86-input-synaptics-1.5.2.tar.gz SHA1: 29d1c66027d9dba06036bb5c7055e08a3bfe64db xf86-input-synaptics-1.5.2.tar.gz SHA256: 82edbf100dd96777cce5c5b5a4a0ab6e65c5fb0964ebe7279ad759b679074bbf xf86-input-synaptics-1.5.2.tar.gz pgpioogl0reSZ.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: synaptics 1.4 series
On Mon, Mar 26, 2012 at 02:15:39AM +0200, Henrik Pauli wrote: > For some reason (probably API incompatibilities), I can't get the 1.3 > nor the 1.5 (1.6) series to work with my current xserver (1.12.0), so > 1.4 or 1.4.1 for me... > > However, there's this weird bug that hasn't ever happened in the past > with a previous (still HAL based etc.) build: my AlpsPS/2 touch pad will > send the cursor to either x=0 or x,y=0,0 coordinates when touched on > certain parts, rendering it entirely unusable. Mouse works, as does the > touch pad in GPM on the console. > > Any idea, anyone? (maybe it's a configuration issue?) probably https://bugs.freedesktop.org/show_bug.cgi?id=47770 though the invalid axis range warnings in your log are a bit worrying as well. Cheers, Peter > Here's a snippet of the Alps-related logs: > > (II) config/udev: Adding input device AlpsPS/2 ALPS GlidePoint > (/dev/input/event8) > (**) AlpsPS/2 ALPS GlidePoint: Applying InputClass "evdev touchpad catchall" > (**) AlpsPS/2 ALPS GlidePoint: Applying InputClass "touchpad catchall" > (**) AlpsPS/2 ALPS GlidePoint: Applying InputClass "touchpad" > (II) LoadModule: "synaptics" > (II) Loading /usr/lib/xorg/modules/input/synaptics_drv.so > (II) Module synaptics: vendor="X.Org Foundation" > compiled for 1.12.0, module version = 1.4.0 > Module class: X.Org XInput Driver > ABI class: X.Org XInput driver, version 16.0 > (II) Using input driver 'synaptics' for 'AlpsPS/2 ALPS GlidePoint' > (**) AlpsPS/2 ALPS GlidePoint: always reports core events > (**) Option "Device" "/dev/input/event8" > (--) AlpsPS/2 ALPS GlidePoint: x-axis range 0 - 1023 > (--) AlpsPS/2 ALPS GlidePoint: y-axis range 0 - 767 > (--) AlpsPS/2 ALPS GlidePoint: pressure range 0 - 127 > (--) AlpsPS/2 ALPS GlidePoint: buttons: left right middle > (--) AlpsPS/2 ALPS GlidePoint: invalid finger width range. defaulting > to 0 - 16 > (**) Option "VertEdgeScroll" "on" > (**) Option "HorizEdgeScroll" "on" > (**) Option "VertTwoFingerScroll" "on" > (**) Option "HorizTwoFingerScroll" "on" > (**) Option "TapButton1" "1" > (**) Option "TapButton2" "2" > (**) Option "TapButton3" "3" > (--) AlpsPS/2 ALPS GlidePoint: touchpad found > (**) AlpsPS/2 ALPS GlidePoint: always reports core events > (**) Option "config_info" > "udev:/sys/devices/platform/i8042/serio2/input/input8/event8" > (II) XINPUT: Adding extended input device "AlpsPS/2 ALPS GlidePoint" > (type: TOUCHPAD, id 15) > (**) AlpsPS/2 ALPS GlidePoint: (accel) MinSpeed is now constant > deceleration 2.5 > (**) AlpsPS/2 ALPS GlidePoint: MaxSpeed is now 1.75 > (**) AlpsPS/2 ALPS GlidePoint: AccelFactor is now 0.156 > (**) AlpsPS/2 ALPS GlidePoint: (accel) keeping acceleration scheme 1 > (**) AlpsPS/2 ALPS GlidePoint: (accel) acceleration profile 1 > (**) AlpsPS/2 ALPS GlidePoint: (accel) acceleration factor: 2.000 > (**) AlpsPS/2 ALPS GlidePoint: (accel) acceleration threshold: 4 > (--) AlpsPS/2 ALPS GlidePoint: touchpad found > (II) config/udev: Adding input device AlpsPS/2 ALPS GlidePoint > (/dev/input/mouse1) > (**) AlpsPS/2 ALPS GlidePoint: Applying InputClass "touchpad catchall" > (**) AlpsPS/2 ALPS GlidePoint: Applying InputClass "touchpad" > (II) Using input driver 'synaptics' for 'AlpsPS/2 ALPS GlidePoint' > (**) AlpsPS/2 ALPS GlidePoint: always reports core events > (**) Option "Device" "/dev/input/mouse1" > (--) AlpsPS/2 ALPS GlidePoint: invalid x-axis range. defaulting to 1615 > - 5685 > (--) AlpsPS/2 ALPS GlidePoint: invalid y-axis range. defaulting to 1729 > - 4171 > (--) AlpsPS/2 ALPS GlidePoint: invalid pressure range. defaulting to 0 > - 256 > (--) AlpsPS/2 ALPS GlidePoint: invalid finger width range. defaulting > to 0 - 16 > (**) Option "VertEdgeScroll" "on" > (**) Option "HorizEdgeScroll" "on" > (**) Option "VertTwoFingerScroll" "on" > (**) Option "HorizTwoFingerScroll" "on" > (**) Option "TapButton1" "1" > (**) Option "TapButton2" "2" > (**) Option "TapButton3" "3" > (EE) Query no Synaptics: 6003C8 > (--) AlpsPS/2 ALPS GlidePoint: no supported touchpad found > (EE) AlpsPS/2 ALPS GlidePoint Unable to query/initialize Synaptics hardware. > (EE) PreInit returned 11 for "AlpsPS/2 ALPS GlidePoint" > > > I guess the last few errors should be suspicious :) > ___ > xorg@lists.x.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.x.org/mailman/listinfo/xorg > Your subscription address: peter.hutte...@who-t.net > ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Key rate limit
On Mon, Mar 26, 2012 at 10:27:46AM -0500, tsuraan wrote: > > In GNOME, it's in the Keyboard Accessibility preferences panel. > > Other desktops with accessibility support should have something similar. > > Hm, so no ideas for a lower-level X11 way of doing it? I suppose I > could try installing the gnome prefs and see if that works under > xmonad. It's certainly worth a shot, anyhow. xkbset http://www.math.missouri.edu/~stephen/software/ Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Key rate limit
On Tue, Mar 27, 2012 at 12:43:49PM -0400, Paul Vojta wrote: > On Mon, Mar 26, 2012 at 11:20:03AM -0500, tsuraan wrote: > > > I am not sure but xset has a [r rate delay [rate]], would that be any > > > help ? > > > > I believe that's for the autorepeat rate, so the rate/delay tells X > > that once the key is held down for ms, it should start firing > > that key at events/s (my units might be wrong though). That's > > sort of the inverse of the problem I have, which is that the keyboard > > seems to be sending a bunch of keypress events really quickly for a > > short period of time. > > > I have a possibly related problem. > > Sometimes I get keystrokes occurring via autorepeat even when no keys are > pressed. They stop when I hit any other key (even shift). > > I've looked into it, and found out that the problem is that the keyboard > (or control chip) is not sending the "break" code until the next key is hit. > Then, since X apparently keeps track of which keys are pressed on its own, > I get the repeated keystrokes. > > Is there a way of telling X to just use the autorepeat provided by the > hardware? not anymore. we've removed this in server 1.6 (iirc) because that and software autorepeat had some weird side-effects. sometimes a key would start hw-repeating before sw-repeat kicked in, causing bursts of keys. and iirc we had the same problem with keys not getting released correctly. that was a time when the whole input system was in a turmoil so it's possible that we could fix this now but I still expect it to be a rather large (and nasty to test) amount of work to get selective hw repeats. Cheers, Peter > The hardware in my case is a Dell XPS M1330 laptop, purchased late 2007. > The problem most often occurs when I release two (or more) keys at very > close to the same time. For example, I switch Control and CapsLock > (ctrl:swapcaps), and to exit a browser I hit Ctrl-W. Since the keys are > so close to each other, I can just use two fingers on the same hand, and > by habit I do it quickly. Then I move over to a terminal window and get > a bunch of w's coming out. > > --Paul Vojta, vo...@math.berkeley.edu > ___ > xorg@lists.x.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.x.org/mailman/listinfo/xorg > Your subscription address: peter.hutte...@who-t.net > ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xinput 1.5.99.901
A few minor fixes on top of the last snapshot. xinput now handles XA_CARDINAL and prints the source ID for raw events (XI 2.2 only). The NVIDIA-specific output checking was improved too. User-visible changes: map-to-crtc was changed to map-to-output I don't expect much more to land before 1.6 is released, if you have any issues with this release, please let me know asap. Peter Hutterer (10): Rename map-to-crtc to map-to-output Fix XRRCrtcInfo memory leaks Enclose property and device names in quotes Always call XCloseDisplay() Don't leak output_info Add find_output_xrandr to check for output presence Replace NVIDIA-specific output checking Handle XA_CARDINAL as property type Print the sourceid for raw events xinput 1.5.99.901 git tag: xinput-1.5.99.901 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.99.901.tar.bz2 MD5: 3b57cb4cbac70eb0d7a553def7dd333e xinput-1.5.99.901.tar.bz2 SHA1: bc99cddeac306a23ad96f35d8ff3314d7e45d460 xinput-1.5.99.901.tar.bz2 SHA256: 4765ca49af591ad5fed1af6847a16b807317212d40d5d21e5f97aa834f3e815e xinput-1.5.99.901.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.99.901.tar.gz MD5: d70f5d31ed4397f14399fd3a562c6f91 xinput-1.5.99.901.tar.gz SHA1: 608df1cc68b40e70132b70250686fb9c38b6ee12 xinput-1.5.99.901.tar.gz SHA256: ed0c852c8f146379767553f5b6924433007c81026e230550351d22fd50be6f7e xinput-1.5.99.901.tar.gz pgp8zH9eaTC6t.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.5.99.903
The new clickpad support is giving us more trouble than we hoped for, so here's another RC with a bunch of fixes. User-visible changes: the scroll delta options now take a negative number to invert the scroll direction. This ability was lost with the switch to smooth scrolling. Alyssa Hung (1): Support inverted scroll direction. Chase Douglas (4): Count number of multitouch touches for multitouch finger count Do not perform a tap action when more than three touches Check touch record bounds before access Use maximum number of touches reported by evdev Peter Hutterer (6): conf: the bcm5974 doesn't have Apple in the product name Define various EVIOCGPROP bits if non-existent Replace hardcoded max number of touches with a define. tools: skip non-existing properties Don't count fingers twice when guessing distance (#48316) synaptics 1.5.99.903 Pierre Lulé (1): Fix coasting speed git tag: xf86-input-synaptics-1.5.99.903 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.99.903.tar.bz2 MD5: 56f125403497c55e0c88130b90c1c7b2 xf86-input-synaptics-1.5.99.903.tar.bz2 SHA1: adb8e28a8aced2ff660a4058d35b8656ffdf46ce xf86-input-synaptics-1.5.99.903.tar.bz2 SHA256: d76f631e8e851ab631f9fde4ec2585be6702c5a28e2a951c9ad9545baf0fb0e2 xf86-input-synaptics-1.5.99.903.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.99.903.tar.gz MD5: 0a2c1d67c47b1a4934321b39d7a32d4a xf86-input-synaptics-1.5.99.903.tar.gz SHA1: fb5759ed3cceae7fdcc15bf6f467d2d2c7c00e9a xf86-input-synaptics-1.5.99.903.tar.gz SHA256: b69576e7157e91e88c8ad8dfef70b3de28fb4553965954981584bb996b69ad39 xf86-input-synaptics-1.5.99.903.tar.gz pgp3xC7hyx6Sa.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Hello World: Error
On Mon, Apr 23, 2012 at 01:55:34PM -0700, Jerrold Clint Balansi wrote: > Hello, > > I am trying to make a Hello World program from code from this site: > http://www.paulgriffiths.net/program/c/srcs/helloxsrc.html > > However, when I try to compile and run it I get this error. Can some give > me a hint. Thank you. > > [root@vizwall Desktop]# gcc -o HelloX HelloX.c gcc -lX11 -o ... Cheers, Peter > > /tmp/ccMGGmGj.o: In function `main': > > HelloX.c:(.text+0x42): undefined reference to `XAllocSizeHints' > > HelloX.c:(.text+0x52): undefined reference to `XAllocWMHints' > > HelloX.c:(.text+0x62): undefined reference to `XAllocClassHint' > > HelloX.c:(.text+0x9d): undefined reference to `XOpenDisplay' > > HelloX.c:(.text+0x219): undefined reference to `XCreateSimpleWindow' > > HelloX.c:(.text+0x232): undefined reference to `XStringListToTextProperty' > > HelloX.c:(.text+0x272): undefined reference to `XStringListToTextProperty' > > HelloX.c:(.text+0x34d): undefined reference to `XSetWMProperties' > > HelloX.c:(.text+0x362): undefined reference to `XSelectInput' > > HelloX.c:(.text+0x373): undefined reference to `XLoadQueryFont' > > HelloX.c:(.text+0x3c1): undefined reference to `XCreateGC' > > HelloX.c:(.text+0x3dd): undefined reference to `XSetFont' > > HelloX.c:(.text+0x40f): undefined reference to `XSetForeground' > > HelloX.c:(.text+0x41f): undefined reference to `XMapWindow' > > HelloX.c:(.text+0x434): undefined reference to `XNextEvent' > > HelloX.c:(.text+0x4c7): undefined reference to `XTextWidth' > > HelloX.c:(.text+0x570): undefined reference to `XDrawString' > > HelloX.c:(.text+0x5a0): undefined reference to `XUnloadFont' > > HelloX.c:(.text+0x5b0): undefined reference to `XFreeGC' > > HelloX.c:(.text+0x5bc): undefined reference to `XCloseDisplay' > > collect2: ld returned 1 exit status > > [root@vizwall Desktop]# > > > > > > -jerrold > ___ > xorg@lists.x.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.x.org/mailman/listinfo/xorg > Your subscription address: peter.hutte...@who-t.net ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.5.99.904
This is likely the last release candidate for synaptics 1.6. There are still a few bugs open, some of which I hope to squash before 1.6 but at least for some of them it's likely that the fixes below have fixed them anyway. If you currently have a bug filed please check this release and close the bug if it is gone. Especially 48777 was likely the cause for a bunch of unrelated cursor jumps, weird loops, and others. Chase Douglas (1): Update src/synproto.c license to the preferred MIT/X11 license Chow Loong Jin (1): Fix coasting friction Peter Hutterer (10): man: move ClickPad documentation into a single area Ensure hw millis are monotonic (#48777) Print millis as unsigned int Don't release the button on TS_3 if TapAndDrag is disabled (#31854) Reset touch state on DeviceOff (#49161) Init num_touches to 0 on start ClickPad is most definitely a bool option. Don't unconditionally divide by scroll_dist_vert (#46617) Reset scroll delta when no finger is touching synaptics 1.5.99.904 Pierre Lulé (1): Stop coasting when two-finger scroll begins git tag: xf86-input-synaptics-1.5.99.904 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.99.904.tar.bz2 MD5: 8c07650a79b160c8f04470219bf1bd84 xf86-input-synaptics-1.5.99.904.tar.bz2 SHA1: 4853bd933fa41b83ff513262cdf6e5b89f22d64b xf86-input-synaptics-1.5.99.904.tar.bz2 SHA256: e2ec1d9bf9f6c76643ff004e3f7451ea5e3ae511cba238642e6736ea804549cf xf86-input-synaptics-1.5.99.904.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.5.99.904.tar.gz MD5: 7494ad1608fc8d917d9707dffced81cd xf86-input-synaptics-1.5.99.904.tar.gz SHA1: 21901e3cf458913fb3ff7a8103c87c99e3f9c676 xf86-input-synaptics-1.5.99.904.tar.gz SHA256: cc25443927a832fa9ea997c6e30fde15dc72cbbe243b6f6b45bddb61a9a26ca5 xf86-input-synaptics-1.5.99.904.tar.gz pgpSyfhyG1oLq.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.6.0
synaptics 1.6 is now available.
A few more fixes since RC4, covering a syspend bug seen mostly on Mac Book
Airs (#49161, reproducible on other machines though) and a fix for coasting
when inverted ('natural') scrolling is enabled.
Users of solaris will see the driver work again now, after the backends got
inadvertantly disabled. Users of currently unsupported platforms will now
see an error message instead of getting a dummy driver without backends.
Niveditha Rau (1):
Include a build for solaris
Peter Hutterer (7):
man: drop mention of shm configuration
man: fix hyphenation
Reset all hardware state on DEVICE_OFF (#49161)
Force SLOTSTATE_EMPTY on DeviceOff
Fail if no backends can be found
Fix coasting for negative scroll directions
synaptics 1.6.0
git tag: xf86-input-synaptics-1.6.0
http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.6.0.tar.bz2
MD5: 68a1f6b021b5ef7a7178af92ceb33dd2 xf86-input-synaptics-1.6.0.tar.bz2
SHA1: 24627bf7e1ac120fceb7a32dcfe3ebc29eddfbd6
xf86-input-synaptics-1.6.0.tar.bz2
SHA256: 89a4b09cd3c5cb05c7627e44d03efcf156c4bcb3c162f50c7963c8b6cb21030a
xf86-input-synaptics-1.6.0.tar.bz2
http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.6.0.tar.gz
MD5: a4b8b65a4c4d531d81aa0455b4208cc8 xf86-input-synaptics-1.6.0.tar.gz
SHA1: 15aee77291505595d3dd794df8919e6a9382a9a3
xf86-input-synaptics-1.6.0.tar.gz
SHA256: eb7e5a2b9c8aa76a96d1d757e7d1055da198a5519c0f6cda9805059a9ebf009c
xf86-input-synaptics-1.6.0.tar.gz
pgpCHENRPpp7L.pgp
Description: PGP signature
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libXi 1.6.1
libXi 1.6.1 is now available. Major bugs fixed: - wrong button and mask copy (doesn't just affect OS X, despite the commit log) - raw event sourceid is now set Chase Douglas (1): Destroy extension record after last display is removed Peter Hutterer (5): Fix wrong button label and mask copy on OS X Move version comparison into a helper function. Set the RawEvent sourceid (#34240) man: update XIQueryVersion for current server behaviour libXi 1.6.1 git tag: libXi-1.6.1 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.6.1.tar.bz2 MD5: 78ee882e1ff3b192cf54070bdb19938e libXi-1.6.1.tar.bz2 SHA1: 4b53b41fdaa3acc86606c696c68d5eed11454612 libXi-1.6.1.tar.bz2 SHA256: f2e3627d7292ec5eff488ab58867fba14a62f06e72a8d3337ab6222c09873109 libXi-1.6.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.6.1.tar.gz MD5: d024a9de73191628f9772893f02054d8 libXi-1.6.1.tar.gz SHA1: 5a27e61f35e443114cac9a3bba046222e1fb667a libXi-1.6.1.tar.gz SHA256: a2aab210068af017314888c64c3a7dd6b5a7933fe50ab89b6e039aadc07dac46 libXi-1.6.1.tar.gz pgpb8R59ElVFI.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.6.1
First stable update to the 1.6 series. The first three patches are the whitespace changes from the master branch to make cherry-picking easier, so if you have distribution-patches you will have to update those. sorry, but you should be upstreaming them anyways :) Two bugs are fixed in this release: - a wrong conversion caused coasting to be triggered on almost all scroll events. This is fixed now, and synclient's cap to CoastingSpeed=20 was removed too. - on clickpads, moving the clicking finger out of the soft button area caused erroneous button events. Peter Hutterer (7): Indent consistently tools: undo indentation in synclient's parameter list whitespace fix Don't check for soft buttons if a button is already down Fix coasting speed trigger tools: coasting speed is not capped at 20, cap it at 255 synaptics 1.6.1 git tag: xf86-input-synaptics-1.6.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.6.1.tar.bz2 MD5: d10a7ee362d015975fbef11c6beaac97 xf86-input-synaptics-1.6.1.tar.bz2 SHA1: 963276a5dd240e84efff28d516f8d23cfeedaa13 xf86-input-synaptics-1.6.1.tar.bz2 SHA256: 1ab1459ea340f371c40be7d6a780e43bdaa2d9799c1de21145e3b5808d0eab3c xf86-input-synaptics-1.6.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.6.1.tar.gz MD5: b657c1b3c67ece8adad506cd81c3f298 xf86-input-synaptics-1.6.1.tar.gz SHA1: 01e917051c1718d19638b1dd46e204aac827a80d xf86-input-synaptics-1.6.1.tar.gz SHA256: 65dc50b575d94fa29bf64781608afe2f644f02b891d4ddb582b7daab6c802eaa xf86-input-synaptics-1.6.1.tar.gz pgpvhzTGdGNV6.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: minor pointer accel fixes
On Sun, May 13, 2012 at 01:08:05PM +0200, Simon Thum wrote:
> Hi all,
>
> I polished some indentation fallout in pointer acceleration code and
> removed a warning that came to my attention. Nothing serious.
both applied, thanks.
Cheers,
Peter
> From ad233d795b8c4eeb2f29a583441720c357c92706 Mon Sep 17 00:00:00 2001
> From: Simon Thum
> Date: Mon, 2 Apr 2012 18:49:53 +0200
> Subject: [PATCH 1/2] dix: indentation fixes for pointer acceleration
>
> Signed-off-by: Simon Thum
> ---
> dix/devices.c | 12
> dix/ptrveloc.c |7 ---
> include/ptrveloc.h | 15 +--
> 3 files changed, 13 insertions(+), 21 deletions(-)
>
> diff --git a/dix/devices.c b/dix/devices.c
> index 7f38865..0c62a01 100644
> --- a/dix/devices.c
> +++ b/dix/devices.c
> @@ -1332,13 +1332,10 @@ InitValuatorClassDeviceStruct(DeviceIntPtr dev, int
> numAxes, Atom *labels,
>
> /* global list of acceleration schemes */
> ValuatorAccelerationRec pointerAccelerationScheme[] = {
> -{PtrAccelNoOp, NULL, NULL, NULL, NULL}
> -,
> +{PtrAccelNoOp, NULL, NULL, NULL, NULL},
> {PtrAccelPredictable, acceleratePointerPredictable, NULL,
> - InitPredictableAccelerationScheme, AccelerationDefaultCleanup}
> -,
> -{PtrAccelLightweight, acceleratePointerLightweight, NULL, NULL, NULL}
> -,
> + InitPredictableAccelerationScheme, AccelerationDefaultCleanup},
> +{PtrAccelLightweight, acceleratePointerLightweight, NULL, NULL, NULL},
> {-1, NULL, NULL, NULL, NULL}/* terminator */
> };
>
> @@ -1375,8 +1372,7 @@ InitPointerAccelerationScheme(DeviceIntPtr dev, int
> scheme)
>
> if (pointerAccelerationScheme[i].AccelInitProc) {
> if (!pointerAccelerationScheme[i].AccelInitProc(dev,
> -
> &pointerAccelerationScheme
> -[i])) {
> +&pointerAccelerationScheme[i])) {
> return FALSE;
> }
> }
> diff --git a/dix/ptrveloc.c b/dix/ptrveloc.c
> index acbb479..28d90a6 100644
> --- a/dix/ptrveloc.c
> +++ b/dix/ptrveloc.c
> @@ -62,9 +62,9 @@
>
> /* fwds */
> int
> - SetAccelerationProfile(DeviceVelocityPtr vel, int profile_num);
> -static double
> +SetAccelerationProfile(DeviceVelocityPtr vel, int profile_num);
>
> +static double
> SimpleSmoothProfile(DeviceIntPtr dev, DeviceVelocityPtr vel, double velocity,
> double threshold, double acc);
> static PointerAccelerationProfileFunc
> @@ -791,7 +791,8 @@ ComputeAcceleration(DeviceIntPtr dev,
> result +=
> 4.0f * BasicComputeAcceleration(dev, vel,
> (vel->last_velocity +
> - vel->velocity) / 2, threshold,
> + vel->velocity) / 2,
> +threshold,
> acc);
> result /= 6.0f;
> DebugAccelF("(dix ptracc) profile average [%.2f ... %.2f] is %.3f\n",
> diff --git a/include/ptrveloc.h b/include/ptrveloc.h
> index 8778646..3bd982a 100644
> --- a/include/ptrveloc.h
> +++ b/include/ptrveloc.h
> @@ -101,48 +101,43 @@ typedef struct _PredictableAccelSchemeRec {
> } PredictableAccelSchemeRec, *PredictableAccelSchemePtr;
>
> extern _X_EXPORT void
> - InitVelocityData(DeviceVelocityPtr vel);
> +InitVelocityData(DeviceVelocityPtr vel);
>
> extern _X_EXPORT void
> - InitTrackers(DeviceVelocityPtr vel, int ntracker);
> +InitTrackers(DeviceVelocityPtr vel, int ntracker);
>
> extern _X_EXPORT BOOL
> ProcessVelocityData2D(DeviceVelocityPtr vel, double dx, double dy, int time);
>
> extern _X_EXPORT double
> -
> BasicComputeAcceleration(DeviceIntPtr dev, DeviceVelocityPtr vel,
> double velocity, double threshold, double acc);
>
> extern _X_EXPORT void
> - FreeVelocityData(DeviceVelocityPtr vel);
> +FreeVelocityData(DeviceVelocityPtr vel);
>
> extern _X_EXPORT int
> - SetAccelerationProfile(DeviceVelocityPtr vel, int profile_num);
> +SetAccelerationProfile(DeviceVelocityPtr vel, int profile_num);
>
> extern _X_EXPORT DeviceVelocityPtr
> GetDevicePredictableAccelData(DeviceIntPtr dev);
>
> extern _X_EXPORT void
> -
> SetDeviceSpecificAccelerationProfile(DeviceVelocityPtr vel,
> PointerAccelerationProfileFunc profile);
>
> extern _X_INTERNAL void
> - AccelerationDefaultCleanup(DeviceIntPtr dev);
> +AccelerationDefaultCleanup(DeviceIntPtr dev);
>
> extern _X_INTERNAL Bool
> -
> InitPredictableAccelerationScheme(DeviceIntPtr dev,
>struct _ValuatorAccelerationRec
> *protoScheme);
>
> extern _X_INTERNAL void
> -
> acceleratePointerPredictable(DeviceIntPtr dev, ValuatorMask *val,
> CARD32 evtime);
>
> extern _X_INTERNA
Re: X server crash due to evdev device - regression
On Fri, May 11, 2012 at 08:41:08PM +0200, Ben Bucksch wrote: > On 11.05.2012 20:36, Ben Bucksch wrote: > >I've upgraded from Ubuntu 11.10 to 12.04, and the X server is now > >crashing. Log excerpt below. lsusb -vv attached. > > Forgot to add: Obviously, that's not an input device. With Ubuntu > 11.10, this was already in the Xorg log as event device (I don't > have the old logs, but I remember), but didn't crash. I have no idea > why an onboard sound card would be recognized as mouse, despite it > reporting "HID" as one device class. does this crash happen on the vanilla X server? 12.04's xserver has too many patches at this point and this really looks like something I've fixed at some point in the not-too-distant past. Please try to reproduce with the stock 1.12 server and file a bug. Attach your evemu recording so I can try to reproduce this. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: X server crash due to evdev device - regression
On Mon, May 14, 2012 at 12:28:38PM +0200, Ben Bucksch wrote: > On 14.05.2012 08:01, Peter Hutterer wrote: > >Please try to reproduce with the stock 1.12 server and file a bug. Attach > >your evemu recording so I can try to reproduce this. > > Sorry, but I can't do anything that involves changing my Xserver on > my production system, installing a separate OS, or compiling X11 > myself. > > The stack and other information you have should suffice to find and > fix the bug in the code. please report this bug in launchpad then. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xinput 1.6.0
Only one more fix since RC1, adding --enable and --disable support as shortcuts to trigger the property to enable or disable the device, respectively. Peter Hutterer (2): Add --enable/--disable support xinput 1.6.0 git tag: xinput-1.6.0 http://xorg.freedesktop.org/archive/individual/app/xinput-1.6.0.tar.bz2 MD5: d2459d35b4e0b41ded26a1d1159b7ac6 xinput-1.6.0.tar.bz2 SHA1: 958b77a2acf52197b9a1e3e3d11e9bc57fbb1e6c xinput-1.6.0.tar.bz2 SHA256: 4ab007d952c76665603bcb82ceb15fd3929d10faf0580fc4873ac16f5f63847e xinput-1.6.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.6.0.tar.gz MD5: 03146d20083a8bd2e3806554b36c7c2b xinput-1.6.0.tar.gz SHA1: cb36f3bde1aabde7c0d0d907124a05eb2597bd28 xinput-1.6.0.tar.gz SHA256: a3117a323cc32c80428dd1604df8d0f87ecbfb03a4975c187475a04f7201dfb7 xinput-1.6.0.tar.gz pgpfPFQ4vGdyk.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XITouchClass and XIDependentTouch
On Thu, May 31, 2012 at 12:03:37AM +0300, Dimitris Zenios wrote: > I have a touch pad which support XITouchClass in XIDependentTouch.When > i XISelectEvent(TouchBegin,TouchEnd,TouchUpdate) i dont get any touch > events originating from the touch pad .Any idea? the synaptics driver doesn't send touch events unless all multi-finger handling is disabled in the driver. This includes all ClickFinger*, TapAction* and *TwoFinger* options. Once you disable those, you'll see touch events. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: X loses wireless input devices
On Sat, Jun 09, 2012 at 07:45:53AM -0700, Yan Seiner wrote: > I have a multiseat setup where 2 of the seats use wireless mice and > keyboards. After some random time measured in hours/days, those two > seats "lose" the input devices. They become non-responsive. The > LEDs on the hardware light up so I know the mice and keyboards are > awake and sending signals, but the X session itself does not > respond. There is nothing interesting in the log files. the one > seat with wired devices is fine. > > If I kill that X client and let kdm restart it, it will work fine > for a while. What information can I provide to help diagnose this? you've disabled hotplugging, so if the device disappears at the kernel level at any point in time, it will not come back until you've restarted the server (VT switch should do too, btw). that is my suspicion here though that should usually print read errors to the logs. there isn't really much you can do about this, the old device model doesn't really lend itself for hotplugging. you also seem to have input devices with no names? what devices are those? (event9 and event10) > Here's xorg.conf: > > Section "ServerLayout" >Identifier "akari" >Screen 0 "akari-scr" 0 0 >InputDevice"akari-kbd" "CoreKeyboard" >InputDevice"akari-mouse" "CorePointer" >Option "AutoEnableDevices" "true" >Option "AutoAddDevices""false" >Option "AllowEmptyInput" "true" btw, we've removed this option in the server because people kept using it, despite it having no useful effect. Cheers, Peter > EndSection > > Section "ServerLayout" >Identifier "jason" >Screen 0 "jason-scr" 0 0 >InputDevice"jason-kbd" "CoreKeyboard" >InputDevice"jason-mouse" "CorePointer" >Option "AutoEnableDevices" "true" >Option "AutoAddDevices""false" >Option "AllowEmptyInput" "true" > EndSection > > Section "ServerLayout" >Identifier "myth" >Screen 0 "myth-scr" 0 0 >InputDevice"myth-kbd" "CoreKeyboard" >InputDevice"myth-mouse" "CorePointer" >Option "AutoEnableDevices" "true" >Option "AutoAddDevices""false" >Option "AllowEmptyInput" "true" > EndSection > > Section "Files" > EndSection > > > Section "InputDevice" >Identifier "akari-mouse" >Driver "evdev" >Option "Device" > "/dev/input/by-path/pci-:00:02.1-usb-0:3.4:1.1-event-mouse" >Option "Emulate3Buttons" "no" >Option "ZAxisMapping" "4 5" > EndSection > > Section "InputDevice" >Identifier "jason-mouse" >Driver "evdev" >Option "Device" > "/dev/input/by-path/pci-:00:02.1-usb-0:1.1:1.0-event-mouse" >Option "Emulate3Buttons" "no" >Option "ZAxisMapping" "4 5" > EndSection > > Section "InputDevice" >Identifier "myth-mouse" >Driver "evdev" >Option "Device" > "/dev/input/by-path/pci-:00:02.1-usb-0:2.4.4.4:1.1-event-mouse" >Option "Emulate3Buttons" "no" >Option "ZAxisMapping" "4 5" > EndSection > > Section "InputDevice" >Identifier "akari-kbd" >Driver "evdev" >Option "Device" > "/dev/input/by-path/pci-:00:02.1-usb-0:3.4:1.0-event-kbd" >Option "XkbRules" "xorg" >Option "XkbModel" "105" >Option "XkbLayout" "us" >Option "Protocol" "Standard" > EndSection > > Section "InputDevice" >Identifier "jason-kbd" >Driver "evdev" >Option "Device" > "/dev/input/by-path/pci-:00:02.1-usb-0:1.2:1.0-event-kbd" >Option "XkbRules" "xorg" >Option "XkbModel" "105" >Option "XkbLayout" "us" >Option "Protocol" "Standard" > EndSection > > Section "InputDevice" >Identifier "myth-kbd" >Driver "evdev" >Option "Device" > "/dev/input/by-path/pci-:00:02.1-usb-0:2.4.4.4:1.0-event-kbd" >Option "XkbRules" "xorg" >Option "XkbModel" "105" >Option "XkbLayout" "us" >Option "Protocol" "Standard" > EndSection > > Section "Monitor" >Identifier "akari-mon" >VendorName "Unknown" >ModelName "Unknown" >Option "DPMS" > EndSection > > Section "Monitor" >Identifier "jason-mon" >VendorName "Unknown" >ModelName "Unknown" >Option "DPMS" > EndSection > > Section "Monitor" >Identifier "myth-mon" >VendorName "Unknown" >ModelName "Unknown" >Option "DPMS" > EndSection > > Section "Device" >Identifier "jason-dev" > #Driver "nvidia" >VendorName "NVIDIA Corporation" >BusID"PCI:2:0:0" >Screen 0 > EndSection > > Section "Device" >Identifier "akari-dev" > #Driver "nvidia" >VendorName "NVIDIA Corporation" >BusID "PCI:4:0:0" >Screen 0 > EndSection
Re: Implementing smooth scrolling in an X client
On Mon, Jun 04, 2012 at 06:50:47PM -0400, Paul Vojta wrote: > Folks: > > I've started working on implementing smooth scrolling in xdvi, and I have a > question about it. > > When I do > > xinput --test 9 > > (where 9 is the deviceid of my Synaptics touchpad) and stroke my finger > down the right-hand side of the touchpad, I get an increasing sequence of > numbers: > > motion a[3]=1935 > motion a[3]=1950 > motion a[3]=1964 > motion a[3]=1979 > motion a[3]=2007 > motion a[3]=2017 > motion a[3]=2034 > motion a[3]=2062 > motion a[3]=2088 > motion a[3]=2124 > motion a[3]=2154 > motion a[3]=2185 > motion a[3]=2210 > > etc. So far I've modified xdvi so that I can get a similar printout from > xdvi. > > I guess that what I'm supposed to do with these numbers is keep track of > the most recently reported number, and scroll based on the differences > between the numbers. correct > But now if I move my mouse to some other window (e.g., xterm), scroll in > that window for a while, and then move back, the numbers reported to > xdvi would reflect the scrolling activity done in the other window. correct > So I would need to keep track of EnterNotify events for each window for > which I'm doing smooth scrolling, and set a flag each time such an event > is received. yes, this is a bug in the protocol and that behaviour is what GTK has to do as well. http://who-t.blogspot.com.au/2012/06/xi-21-protocol-design-issues.html > A problem with this (other than the extra programming effort required) > is that on four-button Synaptics touchpads, the first button press of > the third or fourth button after returning to the xdvi window would > (I think) have no effect anymore. (More generally, the first scrolling > distance would be ignored for every return to the window, but would not > be noticeable unless it was produced by a button press or simulated button > press.) > > Is this correct? are you talking about the touchpads that have separate scroll buttons? I'd not worry too much about those, I think even the newest ones are several years old now (to the point that the next version of synaptics won't support the scroll buttons anymore). > And, more to the point, is there some way by which I could just receive the > deltas of the scrolling valuators for when the pointer is in the designated > window? you can't really get the deltas only, you'll always have to calculate them from the previous value. your only option for not skipping the first event is to run XIQueryDevice after an EnterEvent to get the current value on the valuator so you can use that first event with that delta. Of course, that is prone to race conditions so you have to work around them too. sorry :( Cheers, Peter > I am using Debian on x86_64, with the following package versions: > > xserver-xorg-core 2:1.12.1.902-1 > xserver-xorg-input-synaptics 1.6.1-1 > xinput 1.6.0-1 ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: X loses wireless input devices
On Mon, Jun 11, 2012 at 06:02:48PM -0700, Yan Seiner wrote: > Peter Hutterer wrote: > >On Sat, Jun 09, 2012 at 07:45:53AM -0700, Yan Seiner wrote: > >>I have a multiseat setup where 2 of the seats use wireless mice and > >>keyboards. After some random time measured in hours/days, those two > >>seats "lose" the input devices. They become non-responsive. The > >>LEDs on the hardware light up so I know the mice and keyboards are > >>awake and sending signals, but the X session itself does not > >>respond. There is nothing interesting in the log files. the one > >>seat with wired devices is fine. > >> > >>If I kill that X client and let kdm restart it, it will work fine > >>for a while. What information can I provide to help diagnose this? > > > >you've disabled hotplugging, so if the device disappears at the kernel level > >at any point in time, it will not come back until you've restarted the > >server (VT switch should do too, btw). that is my suspicion here though that > >should usually print read errors to the logs. there isn't really much you > >can do about this, the old device model doesn't really lend itself for > >hotplugging. > By hotplugging you mean setting Option "AutoAddDevices" "true"? If > I do that, every input device gets assigned to every seat, so that > keyboard attached to seat 1 also shows up on seats 2 and 3, and > every mouse moves every cursor. > > Is there any way to limit the pool of "AutoAddDevices" so that it > works correctly with multi-seat? 1.12 has the ID_SEAT support, so if you set that property through udev the server only adds the matching ones. You'd have to then start the X server with -seat, see the commit message to 159b03e13760920274b573a2bccdbf6a79f059e7 for some detail. If you can't update your server, you can use the ID_INPUT.tags udev properties, together with a MatchTag in your xorg.conf InputClass section to limit devices. not as automatic but it'll get you there with hotplugging enabled. Cheers, Peter > >you also seem to have input devices with no names? what devices are those? > >(event9 and event10) > They're whatever udev decides... Not really sure where they came from. > > > > > > > >>Here's xorg.conf: > >> > >>Section "ServerLayout" > >> Identifier "akari" > >> Screen 0 "akari-scr" 0 0 > >> InputDevice"akari-kbd" "CoreKeyboard" > >> InputDevice"akari-mouse" "CorePointer" > >> Option "AutoEnableDevices" "true" > >> Option "AutoAddDevices""false" > >> Option "AllowEmptyInput" "true" > > > >btw, we've removed this option in the server because people kept using it, > >despite it having no useful effect. > OK; not sure where it came from either and it seems to do no harm. :-) > > I'll remove it. > > ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-synaptics 1.6.2
No additional changes since the RC, so here it is only slighlty delayed: synaptics 1.6.2. Fixes include: - #49439: out-of-bounds access if a touch was active at driver init - #49965: disallow scroll distances on 0 to avoid division by 0 - Fix coasting for negative scroll deltas - More fixes to avoid jumpy cursors on resume Peter Hutterer (1): synaptics 1.6.2 git tag: xf86-input-synaptics-1.6.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.6.2.tar.bz2 MD5: 9914022a173e3f0ccfe7137ab84f6133 xf86-input-synaptics-1.6.2.tar.bz2 SHA1: 6e59871c0cb683a1fa84731db73a662727a76976 xf86-input-synaptics-1.6.2.tar.bz2 SHA256: c3f7d6a085d480c352f030aeb43db2e5560d1468ed34be24d44a0fc3fda25920 xf86-input-synaptics-1.6.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-synaptics-1.6.2.tar.gz MD5: 6a374aa03ea64e895991f812c47743b1 xf86-input-synaptics-1.6.2.tar.gz SHA1: ee8c803cc0f15235c290409af3a6f8316d4f4de2 xf86-input-synaptics-1.6.2.tar.gz SHA256: adfe967a891694a5b6fbd9001b365a673d19d96a56092388fc223288e61f714a xf86-input-synaptics-1.6.2.tar.gz pgpZ7HrkEvoLp.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: X loses wireless input devices
On Tue, Jun 12, 2012 at 01:27:58PM -0700, Yan Seiner wrote:
>
> On Mon, June 11, 2012 7:56 pm, Peter Hutterer wrote:
> >
> > 1.12 has the ID_SEAT support, so if you set that property through udev the
> > server only adds the matching ones. You'd have to then start the X server
> > with -seat, see the commit message to
> > 159b03e13760920274b573a2bccdbf6a79f059e7 for some detail.
> >
>
> I have 1.12 installed, and -seat NNN seems to be working; at least when I
> use -seat no devices are detected. I'm having 2 issues:
>
> 1. I'm not familiar with the xorg git repository, and I can't figure out
> how/where to find the commit message you refer to.
>
> 2. I can't find any examples of setting properties or tags in udev.
> Ubuntu does not use systemd, so I'm stuck doing this manually.
>
> Here's one attempt; the symlink is created but X doesn't see any evdev
> devices.
>
> SUBSYSTEM=="input", ACTION=="add",
> ATTRS{phys}=="usb-:00:02.1-2.4.4.4/input0",
> SYMLINK+="input/seat/jason/mouse"
> SUBSYSTEM=="input", ACTION=="add",
> ATTRS{phys}=="usb-:00:02.1-2.4.4.4/input0", ID_SEAT+="jason"
> SUBSYSTEM=="input", ACTION=="add",
> ATTRS{phys}=="usb-:00:02.1-2.4.4.4/input0", TAG+="seat"
>
> Is there an example I can go by?
not that I know of, unfortunately. Did you check whether the property is set
in udevadm info? And which device it is set on? we only check for ID_SEAT
on the device itself and I suspect that the above rules assign it to the
parent device instead.
Cheers,
Peter
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Implementing smooth scrolling in an X client
On Wed, Jun 13, 2012 at 12:15:35PM -0700, Paul Vojta wrote: > On Tue, Jun 12, 2012 at 11:25:08AM +1000, Peter Hutterer wrote: > > On Mon, Jun 04, 2012 at 06:50:47PM -0400, Paul Vojta wrote: > > [snip] > > > > So I would need to keep track of EnterNotify events for each window for > > > which I'm doing smooth scrolling, and set a flag each time such an event > > > is received. > > > > yes, this is a bug in the protocol and that behaviour is what GTK has to do > > as well. > > http://who-t.blogspot.com.au/2012/06/xi-21-protocol-design-issues.html > > Thanks very much for that reference -- it's very helpful. > > > > A problem with this (other than the extra programming effort required) > > > is that on four-button Synaptics touchpads, the first button press of > > > the third or fourth button after returning to the xdvi window would > > > (I think) have no effect anymore. (More generally, the first scrolling > > > distance would be ignored for every return to the window, but would not > > > be noticeable unless it was produced by a button press or simulated button > > > press.) > > > > > > Is this correct? > > > > are you talking about the touchpads that have separate scroll buttons? I'd > > not worry too much about those, I think even the newest ones are several > > years old now (to the point that the next version of synaptics won't support > > the scroll buttons anymore). > > Yes, but also things like RTCornerButton=4, etc. Also, what happens if you > have a traditional wheel mouse in addition to a touchpad? atm, the first scroll event is effectively lost/useless. how much of an issue that is remains to be determined, Carlos said so far there hasn't been a great uproar. > > > And, more to the point, is there some way by which I could just receive > > > the > > > deltas of the scrolling valuators for when the pointer is in the > > > designated > > > window? > > > > you can't really get the deltas only, you'll always have to calculate them > > from the previous value. your only option for not skipping the first event > > is to run XIQueryDevice after an EnterEvent to get the current value on the > > valuator so you can use that first event with that delta. Of course, that is > > prone to race conditions so you have to work around them too. > > OK, thanks. > > > sorry :( > > Any plans to change the spec anytime soon (e.g., for X11R7.8 or XI 2.3)? big maybe, not sure how to fix it yet. the simplest way is of course to add valuator state to the enter events but this may leave some other corner-cases. Either way, it's unlikely this will happen before server 1.14, lack of time. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xorg-server 1.12.2.901
== Description == This is the first release candidate for 1.12.3. The primary changes from the first release candidate pertain to documentation, input and XQuartz. == Known Issues == Currently open bugs the 1.12 Tracker: https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.12 23938: keys occasionally get stuck with xorg-server 1.6.99.901 http://bugs.freedesktop.org/23938 31501: crash accessing font info with xfs in fontpath http://bugs.freedesktop.org/31501 39094: WaitFor does not handle EIO (causes 100% cpu load) http://bugs.freedesktop.org/39094 39383: X server crashes when restarting KDE from Alt+F2 http://bugs.freedesktop.org/39383 39949: RandR panning & scaling don't work http://bugs.freedesktop.org/39949 41124: Xorg crashes while resizing OpenGL windows http://bugs.freedesktop.org/41124 43988: crtc->desiredMode.name can point to freed memory. http://bugs.freedesktop.org/43988 44038: some 3D wine apps no longer work (bisected) http://bugs.freedesktop.org/44038 45445: Key press crashes the xserver when kdm is running http://bugs.freedesktop.org/45445 49170: crash when starting or after some time of using psi http://bugs.freedesktop.org/49170 50641: xorg-server-1.12.0 - When SELinux is enabled the xserver fails http://bugs.freedesktop.org/50641 50683: Black screen with "AutoAddDevices" "Off" http://bugs.freedesktop.org/50683 == New Issues == If you encounter an issue that you think should block a future 1.11 release, please follow the instructions listed in the wiki to raise this to our attention. http://www.x.org/wiki/Server112Branch == Changes since 1.12.1.901 == Alan Coopersmith (4): Undocument mandatory loadable modules Undocument Font Module loading cvt man page should use Hz, not kHz, for vertical refresh rate Convert sbusPaletteKey to latest DevPrivate API Jeremy Huddleston (4): XQuartz: Workaround an SDK bug on Leopard/x86_64 XQuartz: Tiger build fix XQuartz: Provide fls implementation for Tiger XQuartz: Avoid a race in initialization of darwinPointer Julien Cristau (1): Xi: make stub DeleteInputDeviceRequest call RemoveDevice Marcin Slusarz (1): xfree86: fix mouse wheel support for DGA clients Michal Suchanek (1): Fix crash for motion events from devices without valuators Peter Hutterer (2): dix: undo transformation for missing valuators (#49347) configure.ac: Version bump to 1.12.2.901 (1.12.3 RC1) Siddhesh Poyarekar (1): xkb: Allocate size_syms correctly when width of a type increases git tag: xorg-server-1.12.2.901 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.2.901.tar.bz2 MD5: 07e592e690c75e9ae4d5e79d5d3e34ad xorg-server-1.12.2.901.tar.bz2 SHA1: 9431b3a577a133f5b38be3abfe4356191fd7e746 xorg-server-1.12.2.901.tar.bz2 SHA256: 6a5ff9e2fbff26a445d623c42fae5bfa39a8cb3d1ee540446fc24d27aeda5b78 xorg-server-1.12.2.901.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.2.901.tar.gz MD5: e02512d2fc3af13f4006bbd72841394e xorg-server-1.12.2.901.tar.gz SHA1: 986c624a53572306e0ff6d296724c132ad8729ff xorg-server-1.12.2.901.tar.gz SHA256: 2a0461a61cdd949135ad26b6a84ed73956a7b8b0e4b35e87060c8d171ff4f7c5 xorg-server-1.12.2.901.tar.gz pgpNOP74b0ZQE.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Issue with mouse when starting X
On Sun, Jun 17, 2012 at 11:06:24PM -0700, John Ettedgui wrote: > *Sometimes* when X starts it does detect the mouse as seen in the log > but when I move it nothing happens on screen, and doing a cat on the > /dev/input/eventX does not produce anything either when moving the > mouse. if you don't see events on /dev/input/eventX this is a kernel or, more likely, a hardware issue. device going to sleep, losing connection, something like that. Cheers, Peter > To get the mouse to work, most of the time I have to unplug the USB > adapter and replug it, although sometimes I need to switch it with the > keyboard USB adapter. > I am not sure why and how as it does not always happen. > I know of at least one other person with similar symptoms. > > As for my configuration, I am running Arch Linux with a 3.4 Linux > kernel, xorg-server 1.12.2, evdev 2.7.0. > My mouse is a Logitech performance MX with a USB wireless unifying receiver. > My keyboard is a diNovo keyboard with a USB bluetooth receiver. > Xorg is auto-started by kdm which is started by systemd. > > Here is my log: http://pastebin.com/pWnHwF2d > In this one I cold started the computer, then got no mouse so I > unplugged / replugged the receiver but nothing so then I switched they > keyboard and mouse receivers and then it worked. Everything was > working fine before shutting down the computer though. > > Thank you, > John > ___ > xorg@lists.x.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.x.org/mailman/listinfo/xorg > Your subscription address: peter.hutte...@who-t.net > ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Issue with mouse when starting X
On Mon, Jun 18, 2012 at 09:27:21PM -0700, John Ettedgui wrote: > On Mon, Jun 18, 2012 at 9:21 PM, Peter Hutterer > wrote: > > On Sun, Jun 17, 2012 at 11:06:24PM -0700, John Ettedgui wrote: > >> *Sometimes* when X starts it does detect the mouse as seen in the log > >> but when I move it nothing happens on screen, and doing a cat on the > >> /dev/input/eventX does not produce anything either when moving the > >> mouse. > > > > if you don't see events on /dev/input/eventX this is a kernel or, more > > likely, a hardware issue. device going to sleep, losing connection, > > something like that. > > > > Cheers, > > Peter > > > Hi Peter, > > That makes sense. > Do you know of any kernel log I should look into to see that error? > Can I look for something in dmesg? not 100% sure, sorry. best to file a kernel bug. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: multiple keyboard layouts and switch between them - place to set for local user?
On Thu, Jun 21, 2012 at 11:49:10PM +0200, Giuseppe Penone wrote: > I'm running lxde (lubuntu 12.04) and since I need to handle 4 keyboard > layouts and there's no applet allowing this I made it manually this way: > > sudo nano /etc/default/keyboard > > XKBMODEL="pc105" > XKBLAYOUT="it,us,ru,ua" > XKBVARIANT="," > XKBOPTIONS="grp:switch,grp:shift_caps_toggle,terminate:ctrl_alt_bksp,grp_led:scroll" this translates into setxkbmap -layout "it,us,ru,ua" -variant "," -option " " you can run that anytime > this works fine included the keyboard shortcut to switch layout, but I was > wondering if it was possible > somewhere to set this for the logged user only. > actually I'm thinking about writing an applet or an indicator and would > like to be able to avoid the need for > admin rights to add/remove keyboard layouts. if you want it properly set, and remembered, per user, etc. you can either look at xinitrc or, better, extending your desktop environment to handle this. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xorg hotplugging not working for Mouse
On Thu, Jun 21, 2012 at 04:23:18PM +0800, shih dane wrote: > hi all > > i build X.Org X Server 1.11.1 for my machine > keyboard and mouse are both USB > hotplugging not working for mouse > but keyboard work fine > > xf86-input-keyboard-1.6.0 > xf86-input-mouse-1.7.2 > > Xorg.conf > > Section "ServerLayout" > Identifier "X.org Configured" > Screen 0 "Screen0" 0 0 > InputDevice"Mouse0" "CorePointer" > InputDevice"Keyboard0" "CoreKeyboard" > EndSection > > Section "Files" > ModulePath "/opt/xorg/sys/lib/xorg/modules" > EndSection > > Section "Module" > Load "glx" > Load "dri2" > Load "record" > Load "dri" > Load "extmod" > Load "dbe" > EndSection > > Section "ServerFlags" > Option "AutoAddDevices" "False" why do you disable hotplugging if you need hotplugging to work? Cheers, Peter > EndSection > > Section "InputDevice" > Identifier "Keyboard0" > Driver "kbd" > Option "XkbModel" "pc105" > Option "XkbLayout" "us" > EndSection > > Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/mouse0" > EndSection > > Section "Monitor" > Identifier "VGA" > VendorName "none" > ModelName"none" > #HorizSync31.5-90 > #HorizSync28-33 > HorizSync28-90 > VertRefresh 60 > EndSection > > Section "Device" > Identifier "card0" > Driver "fbdev" > BusID "PCI:0:2:0" > Screen 0 > EndSection > > Section "Screen" > Identifier "Screen0" > Device "card0" > Monitor"VGA" > #DefaultDepth 24 > #DefaultFbBpp 32 > SubSection "Display" > Viewport0 0 > Depth 24 > Virtual > EndSubSection > EndSection ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: setting the state of a pointer
On Fri, Jun 22, 2012 at 09:59:42PM +0200, krastanov.ste...@gmail.com wrote: > Due to a problem with a touchscreen the state of the pointer gets > stuck to 0x110. How can I reset the pointer state? Using xdotool and > xte and generating mouse event with them did not work. Using a usb > mouse works, however the state continues to be stuck to 0x110. best to fix the touchscreen drivers. 0x110 means 0x10 (numlock) and 0x100 (button 1). ignore the numlock, so this just means that the touchscreen never sends a button release event (or touch up, depending on what version of X you're running). I'd need to see the evtest output for this device and the xserver/evdev version you're running to say more though. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: setting the state of a pointer
On Mon, Jun 25, 2012 at 11:39:32AM +0200, krastanov.ste...@gmail.com wrote: > Many more details can be found here > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/1015183 Chase, do you have time to look into that? see comment #9 for an analysis Cheers, Peter > I am on different hardware but have the same issues, namely: > > I may use imprecise terminology, I do not know much about X. > > - press, notify and release events are generated by all of the > following: xdotool, usb mouse, the touchscreen itself. xlib python > bindings, and any other tool that I tried > - the state stubbornly rests 0x110 or 0x100 (depending on numlock) > > I will send the output of evtest attached in the following mail. > > On 25 June 2012 03:16, Peter Hutterer wrote: > > On Fri, Jun 22, 2012 at 09:59:42PM +0200, krastanov.ste...@gmail.com wrote: > >> Due to a problem with a touchscreen the state of the pointer gets > >> stuck to 0x110. How can I reset the pointer state? Using xdotool and > >> xte and generating mouse event with them did not work. Using a usb > >> mouse works, however the state continues to be stuck to 0x110. > > > > best to fix the touchscreen drivers. 0x110 means 0x10 (numlock) and 0x100 > > (button 1). ignore the numlock, so this just means that the touchscreen > > never sends a button release event (or touch up, depending on what version > > of X you're running). > > > > I'd need to see the evtest output for this device and the xserver/evdev > > version you're running to say more though. > > > > Cheers, > > Peter > ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xorg hotplugging not working for Mouse
On Tue, Jun 26, 2012 at 11:45:20AM +0800, shih dane wrote: > Hi > i try to modify config > > Option "AutoAddDevices" "True" > > remove all intput device in config > and laod evdev driver > > can not find mouse and keyboad I presume there's some other configuration issue then, but hard to say with this little information. Please provide at least your Xorg.log. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xorg hotplugging not working for Mouse
On Tue, Jun 26, 2012 at 12:29:35PM +0800, shih dane wrote: > 2012/6/26 Peter Hutterer : > > On Tue, Jun 26, 2012 at 11:45:20AM +0800, shih dane wrote: > >> Hi > >> i try to modify config > >> > >> Option "AutoAddDevices" "True" > >> > >> remove all intput device in config > >> and laod evdev driver > >> > >> can not find mouse and keyboad > > > > I presume there's some other configuration issue then, but hard to say with > > this little information. Please provide at least your Xorg.log. > > > > Cheers, > > Peter > > thaks for advice > that's my xorg.log and xorg.conf > > Best Regard > Dane > [ 74984.842] > X.Org X Server 1.11.1 > Release Date: 2011-09-24 > [ 74984.842] X Protocol Version 11, Revision 0 > [ 74984.842] Build Operating System: Linux 2.6.32.16-141.loop_aes.fc12.x86_64 > x86_64 > [ 74984.842] Current Operating System: Linux N10850 2.6.38 #1 SMP Mon Jun 18 > 10:43:00 CST 2012 x86_64 > [ 74984.842] Kernel command line: ro root=/dev/ram0 max_loop=210 > console=ttyS1,115200n8 > [ 74984.842] Build Date: 20 June 2012 04:27:04PM > [ 74984.842] > [ 74984.842] Current version of pixman: 0.24.2 > [ 74984.842] Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > [ 74984.842] Markers: (--) probed, (**) from config file, (==) default > setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [ 74984.842] (==) Log file: "/opt/xorg/sys/var/log/Xorg.0.log", Time: Tue Jun > 26 12:12:08 2012 > [ 74984.842] (++) Using config file: "/opt/xorg/xorg.conf.intel" > [ 74984.842] (==) Using system config directory > "/opt/xorg/sys/share/X11/xorg.conf.d" > [ 74984.842] (==) ServerLayout "X.org Configured" > [ 74984.842] (**) |-->Screen "Screen0" (0) > [ 74984.842] (**) | |-->Monitor "VGA" > [ 74984.842] (**) | |-->Device "card0" > [ 74984.842] (==) Automatically adding devices > [ 74984.842] (==) Automatically enabling devices > [ 74984.842] (WW) The directory "/opt/xorg/sys/share/fonts/X11/misc/" does > not exist. > [ 74984.842] Entry deleted from font path. > [ 74984.842] (WW) The directory "/opt/xorg/sys/share/fonts/X11/TTF/" does not > exist. > [ 74984.842] Entry deleted from font path. > [ 74984.842] (WW) The directory "/opt/xorg/sys/share/fonts/X11/OTF/" does not > exist. > [ 74984.842] Entry deleted from font path. > [ 74984.842] (WW) The directory "/opt/xorg/sys/share/fonts/X11/Type1/" does > not exist. > [ 74984.842] Entry deleted from font path. > [ 74984.842] (WW) The directory "/opt/xorg/sys/share/fonts/X11/100dpi/" does > not exist. > [ 74984.842] Entry deleted from font path. > [ 74984.842] (WW) The directory "/opt/xorg/sys/share/fonts/X11/75dpi/" does > not exist. > [ 74984.842] Entry deleted from font path. > [ 74984.842] (==) FontPath set to: > > [ 74984.842] (**) ModulePath set to "/opt/xorg/sys/lib/xorg/modules" > [ 74984.842] (II) The server relies on HAL to provide the list of input > devices. > If no devices become available, reconfigure HAL or disable > AutoAddDevices. looks like you're on F12 but make sure HAL is running and correctly setup. the log is missing any entries from input devices, suggesting that the server is never notified of their presence. copy config/x11-input.fdi into /etc/hal/fdi/policies/ and restart HAL. http://fedoraproject.org/wiki/Input_device_configuration#Fedora_12_and_earlier has some info here Cheers, Peter > [ 74984.842] (II) Loader magic: 0x7cce40 > [ 74984.842] (II) Module ABI versions: > [ 74984.842] X.Org ANSI C Emulation: 0.4 > [ 74984.842] X.Org Video Driver: 11.0 > [ 74984.842] X.Org XInput driver : 13.0 > [ 74984.842] X.Org Server Extension : 6.0 > [ 74984.843] (--) PCI:*(0:0:2:0) 8086:010a:8086:2010 rev 9, Mem @ > 0x9000/4194304, 0x8000/268435456, I/O @ 0x8000/64 > [ 74984.843] (II) Open ACPI successful (/var/run/acpid.socket) > [ 74984.843] (II) "extmod" will be loaded. This was enabled by default and > also specified in the config file. > [ 74984.843] (II) "dbe" will be loaded. This was enabled by default and also > specified in the config file. > [ 74984.843] (II) "glx" will be loaded. This was enabled by default and also > specified in the config file. > [ 74984.843] (II) "record" will be loaded. This was enabled by default and > also specified in the config file. &
Re: Xorg hotplugging not working for Mouse
On Tue, Jun 26, 2012 at 05:01:35PM +0800, shih dane wrote: > follow > > > > > 2012/6/26 Peter Hutterer : > > On Tue, Jun 26, 2012 at 12:29:35PM +0800, shih dane wrote: > >> 2012/6/26 Peter Hutterer : > >> > On Tue, Jun 26, 2012 at 11:45:20AM +0800, shih dane wrote: > >> >> Hi > >> >> i try to modify config > >> >> > >> >> Option "AutoAddDevices" "True" > >> >> > >> >> remove all intput device in config > >> >> and laod evdev driver > >> >> > >> >> can not find mouse and keyboad > >> > > >> > I presume there's some other configuration issue then, but hard to say > >> > with > >> > this little information. Please provide at least your Xorg.log. > >> > > >> > Cheers, > >> > Peter > >> > >> thaks for advice > >> that's my xorg.log and xorg.conf > >> > >> Best Regard > >> Dane > > > >> [ 74984.842] > >> X.Org X Server 1.11.1 > >> Release Date: 2011-09-24 > >> [ 74984.842] X Protocol Version 11, Revision 0 > >> [ 74984.842] Build Operating System: Linux > >> 2.6.32.16-141.loop_aes.fc12.x86_64 x86_64 > >> [ 74984.842] Current Operating System: Linux N10850 2.6.38 #1 SMP Mon Jun > >> 18 10:43:00 CST 2012 x86_64 > >> [ 74984.842] Kernel command line: ro root=/dev/ram0 max_loop=210 > >> console=ttyS1,115200n8 > >> [ 74984.842] Build Date: 20 June 2012 04:27:04PM > >> [ 74984.842] > >> [ 74984.842] Current version of pixman: 0.24.2 > >> [ 74984.842] Before reporting problems, check http://wiki.x.org > >> to make sure that you have the latest version. > >> [ 74984.842] Markers: (--) probed, (**) from config file, (==) default > >> setting, > >> (++) from command line, (!!) notice, (II) informational, > >> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > >> [ 74984.842] (==) Log file: "/opt/xorg/sys/var/log/Xorg.0.log", Time: Tue > >> Jun 26 12:12:08 2012 > >> [ 74984.842] (++) Using config file: "/opt/xorg/xorg.conf.intel" > >> [ 74984.842] (==) Using system config directory > >> "/opt/xorg/sys/share/X11/xorg.conf.d" > >> [ 74984.842] (==) ServerLayout "X.org Configured" > >> [ 74984.842] (**) |-->Screen "Screen0" (0) > >> [ 74984.842] (**) | |-->Monitor "VGA" > >> [ 74984.842] (**) | |-->Device "card0" > >> [ 74984.842] (==) Automatically adding devices > >> [ 74984.842] (==) Automatically enabling devices > >> [ 74984.842] (WW) The directory "/opt/xorg/sys/share/fonts/X11/misc/" does > >> not exist. > >> [ 74984.842] Entry deleted from font path. > >> [ 74984.842] (WW) The directory "/opt/xorg/sys/share/fonts/X11/TTF/" does > >> not exist. > >> [ 74984.842] Entry deleted from font path. > >> [ 74984.842] (WW) The directory "/opt/xorg/sys/share/fonts/X11/OTF/" does > >> not exist. > >> [ 74984.842] Entry deleted from font path. > >> [ 74984.842] (WW) The directory "/opt/xorg/sys/share/fonts/X11/Type1/" > >> does not exist. > >> [ 74984.842] Entry deleted from font path. > >> [ 74984.842] (WW) The directory "/opt/xorg/sys/share/fonts/X11/100dpi/" > >> does not exist. > >> [ 74984.842] Entry deleted from font path. > >> [ 74984.842] (WW) The directory "/opt/xorg/sys/share/fonts/X11/75dpi/" > >> does not exist. > >> [ 74984.842] Entry deleted from font path. > >> [ 74984.842] (==) FontPath set to: > >> > >> [ 74984.842] (**) ModulePath set to "/opt/xorg/sys/lib/xorg/modules" > >> [ 74984.842] (II) The server relies on HAL to provide the list of input > >> devices. > >> If no devices become available, reconfigure HAL or disable > >> AutoAddDevices. > > > > looks like you're on F12 but make sure HAL is running and correctly setup. > > the log is missing any entries from input devices, suggesting that the > > server is never notified of their presence. copy config/x11-input.fdi into > > /etc/hal/fdi/policies/ and restart HAL > > .. > > http://fedoraproject.org/wiki/Input_device_configuration#Fedora_12_and_earlier > > has some info here > > > > Cheers, > > Peter > follow steps above > also can no
[ANNOUNCE] xorg-server 1.12.2.902
== Description == This is the second release candidate for 1.12.3. A few input changes, avoiding messing up the event queue on some RandR events. A warning is now printed to the log if SlowKeys is turned on. Update on the schedule: This RC should've been released on Friday but I ran out of time and didn't get to it on the weekend either. So I've moved the 1.12.3 release date back, it will 7 days from now, next monday. == Known Issues == Currently open bugs the 1.12 Tracker: https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.12 23938: keys occasionally get stuck with xorg-server 1.6.99.901 http://bugs.freedesktop.org/23938 31501: crash accessing font info with xfs in fontpath http://bugs.freedesktop.org/31501 39094: WaitFor does not handle EIO (causes 100% cpu load) http://bugs.freedesktop.org/39094 39383: X server crashes when restarting KDE from Alt+F2 http://bugs.freedesktop.org/39383 39949: RandR panning & scaling don't work http://bugs.freedesktop.org/39949 43988: crtc->desiredMode.name can point to freed memory. http://bugs.freedesktop.org/43988 44038: some 3D wine apps no longer work (bisected) http://bugs.freedesktop.org/44038 45445: Key press crashes the xserver when kdm is running http://bugs.freedesktop.org/45445 49170: crash when starting or after some time of using psi http://bugs.freedesktop.org/49170 50641: xorg-server-1.12.0 - When SELinux is enabled the xserver fails http://bugs.freedesktop.org/50641 50683: Black screen with "AutoAddDevices" "Off" http://bugs.freedesktop.org/50683 == New Issues == If you encounter an issue that you think should block a future 1.11 release, please follow the instructions listed in the wiki to raise this to our attention. http://www.x.org/wiki/Server112Branch == Changes since 1.12.1.902 == Andy Ritger (1): randr: Don't recurse into mieqProcessInputEvents() from RRTellChanged(). Peter Hutterer (4): xkb: warn if XKB SlowKeys have been automatically enabled Xi: fix XITouchClass sourceid assignment dix: if the scroll valuator reaches INT_MAX, reset to 0 configure.ac: Version bump to 1.12.2.902 (1.12.3 RC2) git tag: xorg-server-1.12.2.902 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.2.902.tar.bz2 MD5: 74175b023bdd46244c1ba6c50735c011 xorg-server-1.12.2.902.tar.bz2 SHA1: ad084777de751076f9459e5e6e5485f504992638 xorg-server-1.12.2.902.tar.bz2 SHA256: 3de52fb923aed147c03d0ef6f5c5f0cf7a0bd57bac860bae66d636fcfa0031a6 xorg-server-1.12.2.902.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.2.902.tar.gz MD5: 8abe6384130238546623e32edd92ecbf xorg-server-1.12.2.902.tar.gz SHA1: e43b8891bfd8ad5238223a92c71340bba88fc3c7 xorg-server-1.12.2.902.tar.gz SHA256: 7cc971895d7c03bbc189016771dfbe16d1ca3303ea1ef17215f38d0513a52036 xorg-server-1.12.2.902.tar.gz pgp17fhBVBoKG.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xorg-server 1.12.3
== Description == The third stable update to the X.Org X server 1.12 series is now available. A few smaller changes only since the second RC, some memory leak fixes and two fixes to avoid out-of-bounds array access. == Known Issues == Currently open bugs the 1.12 Tracker: https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.12 23938: keys occasionally get stuck with xorg-server 1.6.99.901 http://bugs.freedesktop.org/23938 31501: crash accessing font info with xfs in fontpath http://bugs.freedesktop.org/31501 39094: WaitFor does not handle EIO (causes 100% cpu load) http://bugs.freedesktop.org/39094 39383: X server crashes when restarting KDE from Alt+F2 http://bugs.freedesktop.org/39383 39949: RandR panning & scaling don't work http://bugs.freedesktop.org/39949 43988: crtc->desiredMode.name can point to freed memory. http://bugs.freedesktop.org/43988 44038: some 3D wine apps no longer work (bisected) http://bugs.freedesktop.org/44038 45445: Key press crashes the xserver when kdm is running http://bugs.freedesktop.org/45445 49170: crash when starting or after some time of using psi http://bugs.freedesktop.org/49170 50641: xorg-server-1.12.0 - When SELinux is enabled the xserver fails http://bugs.freedesktop.org/50641 == New Issues == If you encounter an issue that you think should block a future 1.12 release, please follow the instructions listed in the wiki to raise this to our attention. http://www.x.org/wiki/Server112Branch == Changes since 1.12.2.902 == Peter Hutterer (5): xfree86: fix use-after-free issue in checkInput dix: fix memory leak in TouchEventHistoryReplay Xi: extend PropagateMask to EMASKSIZE xfree86: always enable SIGIO on OsVendorInit (#50957) configure.ac: Bump to Version 1.12.3 Torsten Kaiser (2): xfree86: EDID Est III parsing can walk off end of array xfree86: EDID Est III parsing skips some modes git tag: xorg-server-1.12.3 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.3.tar.bz2 MD5: 65a53b11bc01dcc97ee9b201dc620c32 xorg-server-1.12.3.tar.bz2 SHA1: f3f3d59f3c5e15459152987ffc644f06a0d1374f xorg-server-1.12.3.tar.bz2 SHA256: 3654b613393734ce0c7c23e81ca4ceb6e8afefb5f0649233ffd105c1220544fe xorg-server-1.12.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.3.tar.gz MD5: 1ad32a8683351b3beaea719035a46773 xorg-server-1.12.3.tar.gz SHA1: 808b9f42a98b199bfd1178d7a8ee471f71609d40 xorg-server-1.12.3.tar.gz SHA256: ed7efe517715bfa489ae9a682602969011c8122033b3aad33da27786ea626598 xorg-server-1.12.3.tar.gz pgp537qO3MM5f.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Odd issues with Cando touch screen
On Sun, Jul 08, 2012 at 08:29:40PM +, Chandler Paul wrote: > Hello, I just recently got my hands on a Lenovo S10-3t, and installed Gentoo > on it. Everything seems to work, however I am having two problems with the > touch screen related to Xorg. > For one, evdev does not seem to honor my settings no matter what I do. I have > tried to turn on the option "ThirdButtonEmulation" With evdev so that doing a > long press on a spot on the screen will have evdev emulate a right click, > however even though I can see that Xorg does indeed have the option turned > on, it does not actually seem to take affect. I have already checked to make > sure that Xfce was not interferring with the settings by trying it in plain > Xorg with twm, however it still seems to act the same. > In addition, I also am unable to interact with window borders in Xfce with my > touch screen. I am not sure whether or not this is the fault of Xfce or Xorg, > so I figured I might as well ask this here too. Basically, whenever I try to > move, close, minimize, etc. any window by using it's title bar, nothing > happens. The title bar seems to completely ignore any input from the touch > screen, however if I try to do the same with my touchpad I encounter no > issues. > I've already asked forums, the Gentoo mailing lists, IRC chat rooms, and I've > still yet to come up with a solution to this issue, I'm almost starting to > think it's actually a bug with Xorg. Hopefully I'll be able to find some sort > of solution here. hard to tell without any log but my suspicions: - right mouse button emulation only works for non-multitouch touchscreens. if your touchscreen does speak the kernel's touch event protocol, the right button emulation won't be handled in the driver, it's expected to be handled in the client stack evtest should tell you, if you see ABS_MT_POSITION_X, etc. come in for touches then you can't use the driver's button emulation - use xev to look at what events are sent by the device. if they look normal, the issue is unlikely in the server. one possibility is that your WM registers for touch events but doesn't do anything with them? does the touchscreen work otherwise? Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Odd issues with Cando touch screen
On Sun, Jul 08, 2012 at 09:54:34PM +, Chandler Paul wrote: > On Mon, 9 Jul 2012 11:41:25 +1000 > Peter Hutterer wrote: > > > On Sun, Jul 08, 2012 at 08:29:40PM +, Chandler Paul wrote: > > > Hello, I just recently got my hands on a Lenovo S10-3t, and > > > installed Gentoo on it. Everything seems to work, however I am > > > having two problems with the touch screen related to Xorg. For one, > > > evdev does not seem to honor my settings no matter what I do. I > > > have tried to turn on the option "ThirdButtonEmulation" With evdev > > > so that doing a long press on a spot on the screen will have evdev > > > emulate a right click, however even though I can see that Xorg does > > > indeed have the option turned on, it does not actually seem to take > > > affect. I have already checked to make sure that Xfce was not > > > interferring with the settings by trying it in plain Xorg with twm, > > > however it still seems to act the same. In addition, I also am > > > unable to interact with window borders in Xfce with my touch > > > screen. I am not sure whether or not this is the fault of Xfce or > > > Xorg, so I figured I might as well ask this here too. Basically, > > > whenever I try to move, close, minimize, etc. any window by using > > > it's title bar, nothing happens. The title bar seems to completely > > > ignore any input from the touch screen, however if I try to do the > > > same with my touchpad I encounter no issues. I've already asked > > > forums, the Gentoo mailing lists, IRC chat rooms, and I've still > > > yet to come up with a solution to this issue, I'm almost starting > > > to think it's actually a bug with Xorg. Hopefully I'll be able to > > > find some sort of solution here. > > > > hard to tell without any log but my suspicions: > > - right mouse button emulation only works for non-multitouch > > touchscreens. if your touchscreen does speak the kernel's touch event > > protocol, the right button emulation won't be handled in the driver, > > it's expected to be handled in the client stack > > evtest should tell you, if you see ABS_MT_POSITION_X, etc. come in > > for touches then you can't use the driver's button emulation > > - use xev to look at what events are sent by the device. if they look > > normal, the issue is unlikely in the server. one possibility is > > that your WM registers for touch events but doesn't do anything with > > them? does the touchscreen work otherwise? > > > > Cheers, > > Peter > > Well you just answered a question that many hours of Googling could not, and > I apologize for not including a log (I included one this time), all the other > places I included the log didn't really seem to pay much attention to it. My > screen is multitouch, so how would you recommend I go about doing right click > emulation if I cannot do it with the evdev driver? > Also yes, my touch screen does work otherwise, I have not tried actually > taking advantage of the multitouch feature yet though. though. > (sorry for the double-send, I forgot to forward this to the mailing list the > first time, I'm still quite new to these mailing lists shinanigans) if you don't need the actual multitouch support you can hack up evdev to undefine MULTITOUCH and it should handle the other events correctly. if the screen works otherwise but not in xfce, I suspect it's an Xfce issue since the server doesn't treat the WM any different to otehe clients. Cheers, Peter > [ 5556.745] > X.Org X Server 1.12.2 > Release Date: 2012-05-29 > [ 5556.746] X Protocol Version 11, Revision 0 > [ 5556.746] Build Operating System: Linux 3.3.8-gentoo-Lyude-Werewolf x86_64 > Gentoo > [ 5556.746] Current Operating System: Linux Werewolf > 3.3.8-gentoo-Lyude-Werewolf #2 SMP Sat Jul 7 02:44:13 UTC 2012 x86_64 > [ 5556.746] Kernel command line: root=/dev/sda7 #real_root=/dev/sda7 > [ 5556.746] Build Date: 06 July 2012 03:05:25PM > [ 5556.746] > [ 5556.746] Current version of pixman: 0.26.0 > [ 5556.746] Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > [ 5556.746] Markers: (--) probed, (**) from config file, (==) default > setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [ 5556.746] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Jul 8 17:21:57 > 2012 > [ 5556.747] (==) Using config directory: "/etc/X11/xorg.conf
Re: Odd issues with Cando touch screen
On Mon, Jul 09, 2012 at 12:15:17AM +, Chandler Paul wrote: > On Mon, 9 Jul 2012 14:07:07 +1000 > Peter Hutterer wrote: > > > if you don't need the actual multitouch support you can hack up evdev > > to undefine MULTITOUCH and it should handle the other events > > correctly. > > > > if the screen works otherwise but not in xfce, I suspect it's an Xfce > > issue since the server doesn't treat the WM any different to otehe > > clients. > > > > Cheers, > > Peter > > Is there no easy way to do it with multitouch being enabled? no, sorry. the driver treats multitouch devices as such and passes on the multitouch events. only by purposely disabling can you force the driver back into the old mode (which technically isn't done by the driver either, it's just that the driver then only sees some events from the kernel and the kernel does legacy event emulation). Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Odd issues with Cando touch screen
On Mon, Jul 09, 2012 at 02:00:52AM +, Chandler Paul wrote: > On Mon, 9 Jul 2012 15:33:08 +1000 > Peter Hutterer wrote: > > > On Mon, Jul 09, 2012 at 12:15:17AM +, Chandler Paul wrote: > > > On Mon, 9 Jul 2012 14:07:07 +1000 > > > Peter Hutterer wrote: > > > > > > > if you don't need the actual multitouch support you can hack up > > > > evdev to undefine MULTITOUCH and it should handle the other events > > > > correctly. > > > > > > > > if the screen works otherwise but not in xfce, I suspect it's an > > > > Xfce issue since the server doesn't treat the WM any different to > > > > otehe clients. > > > > > > > > Cheers, > > > > Peter > > > > > > Is there no easy way to do it with multitouch being enabled? > > > > no, sorry. the driver treats multitouch devices as such and passes on > > the multitouch events. only by purposely disabling can you force the > > driver back into the old mode (which technically isn't done by the > > driver either, it's just that the driver then only sees some events > > from the kernel and the kernel does legacy event emulation). > > > > Cheers, > > Peter > > Would a patch to change this behavior be possible, or programming > something to react to the events being passed by the drivers and > emulate a right click? > Also, for the time being something should be added to the evdev man > page regarding this, as that would have saved me a lot of time in > trying to figure out this matter. I'll add a section about MT support the man page (once I get to it) but I don't want this to be a configurable behaviour. getting MT right is difficult to begin with and having these behaviours configurable makes coding, debugging and triaging a lot harder. we're in that transition phase of some drivers/devices having MT support, others not, the client stack having partial support so things just don't work perfectly smooth yet. hacks we put in now may solve some pain short term, but will come back to bite us later. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Odd issues with Cando touch screen
On Mon, Jul 09, 2012 at 08:22:36PM +, Chandler Paul wrote: > On Tue, 10 Jul 2012 10:22:09 +1000 > Peter Hutterer wrote: > > > I'll add a section about MT support the man page (once I get to it) > > but I don't want this to be a configurable behaviour. getting MT > > right is difficult to begin with and having these behaviours > > configurable makes coding, debugging and triaging a lot harder. > > > > we're in that transition phase of some drivers/devices having MT > > support, others not, the client stack having partial support so > > things just don't work perfectly smooth yet. hacks we put in now may > > solve some pain short term, but will come back to bite us later. > > So if anything like this were to be done, I'd be much better trying to > implement it into the DE or the like instead of the actual drivers then? yes. try to get proper support into the various clients/toolkits. e.g. GTK already converts a long touch to a right click. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Keyboardmapping with evdev
On Thu, Jul 12, 2012 at 10:05:37AM +0200, Daniel Spannbauer wrote: > Am 07/12/2012 08:33 AM, schrieb Daniel Spannbauer: > > Hello, > > > > I try to get a german keyboard mapping on our own keyboard on a machine > > with opensuse 11.4 (Xorg 7.6) and fglrx 8.930. > > > > My conf seems to be ok... > > > > - > > Section "InputClass" > > Identifier "evdev keyboard catchall" > > MatchIsKeyboard "on" > > MatchDevicePath "/dev/input/event*" > > Driver "evdev" > > EndSection > > > > > > Section "InputClass" > > Identifier "LocalKeyboard" > > MatchIsKeyboard "on" > > Option "XkbLayout" "de" > > EndSection > > - > > > > > > According to the Xorg.0.log ( http://paste.opensuse.org/5436713 )the > > german keyboard mapping should be active...but it is not. The layout is > > still "us". please don't attach logs as pastebins. your post is set to expire in 4 weeks, after which it loses all information to future readers. so it may help you right now, but there's nothing left for posterity. > > If I connect a USB-Keyboard at the same time the layout on that > > USB-Keyboard is german. After I press one key on that usb-keyboard our > > own keyboard is also german. > > > > Can anybody help me to figure out the problem? At normal circumstances I > > can't connect an other keyboard. > > > Additional Info: > > If I do a "setxkbmap -query -verbose 10" I get the following: > > --- > Setting verbose level to 10 > locale is C > Applied rules from evdev: > rules: evdev > model: evdev > layout: de > Trying to build keymap using the following components: > keycodes: evdev+aliases(qwertz) > types: complete > compat: complete > symbols:pc+de+inet(evdev)+terminate(ctrl_alt_bksp) > geometry: pc(pc104) > rules: evdev > model: evdev > layout: de > --- > > But the Keyboard is still us/english. After a "setxkbmap de" the > Keyboard is german. > > Any ideas? I suspect your desktop environment (GNOME? KDE?) overrides your choice of xorg.conf. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Keyboardmapping with evdev
On Fri, Jul 13, 2012 at 08:21:14AM +0200, Daniel Spannbauer wrote: > Am 07/13/2012 08:03 AM, schrieb Peter Hutterer: > > On Thu, Jul 12, 2012 at 10:05:37AM +0200, Daniel Spannbauer wrote: > >> Am 07/12/2012 08:33 AM, schrieb Daniel Spannbauer: > >>> Hello, > >>> > >>> I try to get a german keyboard mapping on our own keyboard on a machine > >>> with opensuse 11.4 (Xorg 7.6) and fglrx 8.930. > >>> > >>> My conf seems to be ok... > >>> > >>> - > >>> Section "InputClass" > >>> Identifier "evdev keyboard catchall" > >>> MatchIsKeyboard "on" > >>> MatchDevicePath "/dev/input/event*" > >>> Driver "evdev" > >>> EndSection > >>> > >>> > >>> Section "InputClass" > >>> Identifier "LocalKeyboard" > >>> MatchIsKeyboard "on" > >>> Option "XkbLayout" "de" > >>> EndSection > >>> - > >>> > >>> > >>> According to the Xorg.0.log ( http://paste.opensuse.org/5436713 )the > >>> german keyboard mapping should be active...but it is not. The layout is > >>> still "us". > > > > please don't attach logs as pastebins. your post is set to expire in 4 > > weeks, after which it loses all information to future readers. so it may > > help you right now, but there's nothing left for posterity. > > > > hmmm, you are right, in the future I will post logs directly here... > > > > > >>> If I connect a USB-Keyboard at the same time the layout on that > >>> USB-Keyboard is german. After I press one key on that usb-keyboard our > >>> own keyboard is also german. > >>> > >>> Can anybody help me to figure out the problem? At normal circumstances I > >>> can't connect an other keyboard. > >> > >> > >> Additional Info: > >> > >> If I do a "setxkbmap -query -verbose 10" I get the following: > >> > >> --- > >> Setting verbose level to 10 > >> locale is C > >> Applied rules from evdev: > >> rules: evdev > >> model: evdev > >> layout: de > >> Trying to build keymap using the following components: > >> keycodes: evdev+aliases(qwertz) > >> types: complete > >> compat: complete > >> symbols:pc+de+inet(evdev)+terminate(ctrl_alt_bksp) > >> geometry: pc(pc104) > >> rules: evdev > >> model: evdev > >> layout: de > >> --- > >> > >> But the Keyboard is still us/english. After a "setxkbmap de" the > >> Keyboard is german. > >> > >> Any ideas? > > > > I suspect your desktop environment (GNOME? KDE?) overrides your choice of > > xorg.conf. > > I don't think so.if I don't start any desktop environment (simply a > xterm) I have the same result. Normaly, we use twm which don't has an > ability to change the keyboard settings. > > Also in kdm (login manager) my keyboard is wrong. The USB-Keyboard seems > to work correctly. do you start X directly or through kdm? i'm pretty sure kdm changes the layout. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-evdev 2.7.1
First update to the evdev 2.7 series. This update fixes a couple of bugs and memory leaks. Chase Douglas (2): Report the correct number of touches for MT protocol B devices Fix buffer overrun when populating axis label property array Peter Hutterer (5): Fix inverted horizontal scroll (#46205) Devices configured as mice need REL_X/Y Release mtdev data whenever we close the fd Close the fd when mtdev open fails evdev 2.7.1 git tag: xf86-input-evdev-2.7.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.7.1.tar.bz2 MD5: fa7660c6fb09a8365289219d4d1de0e5 xf86-input-evdev-2.7.1.tar.bz2 SHA1: 15847129d7d48bcdba56eae8f60421170aea496d xf86-input-evdev-2.7.1.tar.bz2 SHA256: 1c128bbd34bc17d08cc723c2429cdfe7efc426cb753e38189ffd290002a3b598 xf86-input-evdev-2.7.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.7.1.tar.gz MD5: 22b3a764f4c7ad88ff11f2ebba45cae3 xf86-input-evdev-2.7.1.tar.gz SHA1: de2c9a8e10be364422e3a16c9dfce33778c1cf14 xf86-input-evdev-2.7.1.tar.gz SHA256: cfb2aa209ae945c392c105489b2845adba835e89d920ec767d72490cf7132a23 xf86-input-evdev-2.7.1.tar.gz pgpD6jtiNx77L.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Cooirdinate transformation matrix does not work properly with evdev and cando touch screen
On Tue, Jul 24, 2012 at 12:26:45AM +, Chandler Paul wrote: > Hi, I've seen this bug posted already (I commented it on it too), but I > figured I might as well ask this here since it doesn't look like the bug > report has been touched by anyone in quite a while: > When using my netbook's cando touch screen and trying to use the Cooirdinate > Transformation Matrix option, the cursor seems to jump around in a specific > pattern (I can't describe it very well, but it's already been described here > anyway: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/774938 ). > The Ubuntu development seems to already have made a patch for it, but it > doesn't seem like there is any fix for this upstream yet. Is there any chance > this patch could be merged upstream so that the fix is no longer specific to > Ubuntu? are we talking about https://bugs.freedesktop.org/show_bug.cgi?id=49347? if not, please request that the ubuntu dev's upstream the patch or point to the freedesktop bug report. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Cooirdinate transformation matrix does not work properly with evdev and cando touch screen
On Tue, Jul 24, 2012 at 01:53:20AM +, Chandler Paul wrote: > On Tue, 24 Jul 2012 15:51:10 +1000 > Peter Hutterer wrote: > > > > > are we talking about > > https://bugs.freedesktop.org/show_bug.cgi?id=49347? > > > > if not, please request that the ubuntu dev's upstream the patch or > > point to the freedesktop bug report. > > > > Cheers, > > Peter > > Yes, this is regarding that bug. I already made a comment regarding this > on the bug, however I figured I should post it here too since it seems the > bug hasn't been looked at for a while now (I hope there isn't an issue with > that). There was a bug on launchpad however regarding this exact issue, and > they did make a patch for evdev there. The same patch could be merged into > upstream evdev and fix the bug for the rest of the Xorg community. I don't see a comment from you on this bug and it's closed as fixed. which bug are you referring to? Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Fatal IO error 11 (Resource temporarily unavailable) on X server :0
On Tue, Jul 24, 2012 at 06:15:34PM +0200, Giuseppe Penone wrote: > Hi, > on a gtkmm 3 app I'm working on it happened once to have a crash and read > the message: > > Gdk-WARNING **: centro: Fatal IO error 11 (Resource temporarily > unavailable) on X server :0. > > Could this be a problem in my application or is for sure a bug in xorg? if the server crashes when you use your app, it's a server bug. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: command line retrieve list of kbd layouts and variants (to use with setxkbmap)
On Wed, Jul 25, 2012 at 08:34:00AM +0200, Giuseppe Penone wrote: > Hi, is there a way from command line to retrieve the list of all available > keyboard layouts and relative variants? > > I need to list all the available layout/variants choices to be used then > from setxkbmap. > > Also about the layout toggle options, is there a way to retrieve a list of > all available choices > (e.g. grp:shift_caps_toggle , ...) man xkeyboard-config :) Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-elographics 1.4.0
This version brings one change that warrants the minor version jump: previously, the device had a hard-coded device name of "TOUCHSCREEN", and a type name of "Elographics TouchScreen". This release aligns the driver behaviour with other input devices, setting the type_name to TOUCHSCREEN and using the xorg.conf identifier as device name. The option "DeviceName", previously available to override the device name, has been removed - use the InputDevice section's Identifier instead. Peter Hutterer (7): Fix name and type_name for elographics Use xf86SetStrOption for Option Device Don't free on init failure, let UnInit take care of it. Test the device in PreInit and fail if it cannot be opened. Swap calls to Error() to ErrorF Constify a few strings elographics 1.4.0 Terry Lambert (1): Return proper default for unknown values in pInfo->device_control. git tag: xf86-input-elographics-1.4.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-elographics-1.4.0.tar.bz2 MD5: 52be691daa47729e66a807bfe367758f xf86-input-elographics-1.4.0.tar.bz2 SHA1: be0faa79c3e341d4a646eaac7e0452952460b37a xf86-input-elographics-1.4.0.tar.bz2 SHA256: 86b2c80638103c33a65904a97bad5f3e28f556e921778427a7befc99942f3b15 xf86-input-elographics-1.4.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-elographics-1.4.0.tar.gz MD5: 1b8cde2814b1238b2c8ff7fd4a2e1c55 xf86-input-elographics-1.4.0.tar.gz SHA1: fd4db47325e184f1291eb2627829324e1f7ec260 xf86-input-elographics-1.4.0.tar.gz SHA256: f1b36ae19bcaa45b75e048826c0a3da3e3167aff32e8a0c14e5a87d960a05833 xf86-input-elographics-1.4.0.tar.gz pgpE9VidIUNtr.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: How to get xinput reflect evdev driver's absinfo changes ?
On Fri, Jul 27, 2012 at 09:55:59PM +0200, Yann Cantin wrote: > Hi, > > I'm currently working on a kernel input driver for a pointing device that > need runtime > calibration. > > The xorg evdev driver correctly detect and use it, my calibration app update > evdev's > absinfo with a : > > prop = XInternAtom(display, "Evdev Axis Calibration", False); > ... > XIChangeProperty(display, device_id, prop, XA_INTEGER, 32, PropModeReplace, > data.c, 4); > > and the pointing device works like a charm. > > But : when a do a > > xinput --list --long 11 > > after calibration, i get that : > > USB eBeam 2650:1311 id=11 [slave pointer (2)] > Reporting 3 classes: > Class originated from: 11 > Buttons supported: 5 > Button labels: Button Left Button Middle Button Right Button > Wheel Up Button Wheel Down > Button state: > Class originated from: 11 > Detail for Valuator 0: > Label: Abs X > Range: 0.00 - 65535.00 > Resolution: 0 units/m > Mode: absolute > Current value: 22032.00 > Class originated from: 11 > Detail for Valuator 1: > Label: Abs Y > Range: 0.00 - 65535.00 > Resolution: 0 units/m > Mode: absolute > Current value: 43433.00 > > > See the Range ? that's still the data gathered when the device is probed, > without calibration. > After calibration, the ranges should be 0 - screen-width and 0 - > screen-height (the kernel > driver does the maths). > > This isn't a show-stopper (device is working) but i suspect that the input > layer play > ping-pong with the valuators : > > driver/evdev -- xinput -- screen > 0-1279 -> 0-65535 -> 0-1279 > > So, is there a way to adapt xinput's valuators, or even to entirely disable > scaling, as the > kernel driver will throw valid screen coordinates ? the evdev driver updates the axis ranges internally, but the server has (for historical reasons) no facilities to update the axis range of a device at runtime yet. So evdev simply scales the new range into the given range. If the kernel changes at runtime, evdev has no way to detect this, and afaik there's no kernel API to be notified of this either. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: How to get xinput reflect evdev driver's absinfo changes ?
On Mon, Jul 30, 2012 at 04:11:15PM +0200, Yann Cantin wrote: > >> So, is there a way to adapt xinput's valuators, or even to entirely > >> disable scaling, as the > >> kernel driver will throw valid screen coordinates ? > > > > the evdev driver updates the axis ranges internally, but the server has (for > > historical reasons) no facilities to update the axis range of a device at > > runtime yet. So evdev simply scales the new range into the given range. If > > the kernel changes at runtime, evdev has no way to detect this, and afaik > > there's no kernel API to be notified of this either. > > Ok. > > Is it OK and safe to leave a 0-65535 range by default ? yes, even though it's not visible, the calibration is appplied. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-mouse 1.8.1
Aside from the compiler warning fixes, this update brings a change for packagers (and potentially clients, if any exist). The pkgconfig file added with the 1.8.0 release did not get installed and had a different naming convention to other input drivers. Both issues have been addressed and if you currently package (or query for) xf86-mouse.pc you will need to change this to xorg-mouse.pc with this release. Alan Coopersmith (1): Fix compiler warning in sun_mouse.c (Solaris-only) Peter Hutterer (4): Fix compiler warnings Install xf86-mouse.pc file Rename xf86-mouse.pc to xorg-mouse.pc xf86-input-mouse 1.8.1 git tag: xf86-input-mouse-1.8.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-mouse-1.8.1.tar.bz2 MD5: f314c56e4ac6c8fc0cc2710892d5776e xf86-input-mouse-1.8.1.tar.bz2 SHA1: e00e825c9506b7b9c31bf4b8a3a609df8ef408c1 xf86-input-mouse-1.8.1.tar.bz2 SHA256: f5b97aac9aab8fa8b933e960631441ae23b18681c8bf3d5007c00da838f9c9c8 xf86-input-mouse-1.8.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-mouse-1.8.1.tar.gz MD5: afca29dc6aedfc1a1ddbd7e7c161455c xf86-input-mouse-1.8.1.tar.gz SHA1: 94fcc5135f2ddf8062396058bb9564ba0e0e4fb9 xf86-input-mouse-1.8.1.tar.gz SHA256: c5ccd41e078b71654d14f8000b90ca062bebb0bcc299751e19696ecb091ecd80 xf86-input-mouse-1.8.1.tar.gz pgpTKKrAlmNPn.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-evdev 2.7.2
Second update to the evdev 2.7 series. This update fixes a few compiler warnings and a memory leak. Daniel Stone (1): Fix compilation warnings for non-multitouch builds Marcin Slusarz (1): Fix some obvious constness-related compile warnings. Peter Hutterer (4): strtol doesn't need a empty string, NULL is good enough. Constify InputDriverRec->default_options Don't re-open mtdev after PreInit evdev 2.7.2 git tag: xf86-input-evdev-2.7.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.7.2.tar.bz2 MD5: e1da5be7f946bfcd9eb7201bc95da67c xf86-input-evdev-2.7.2.tar.bz2 SHA1: 7b39f9513557ea37528275e9b459546e85b4a72f xf86-input-evdev-2.7.2.tar.bz2 SHA256: ef729a0e4623e278e1d18801a6c3e4565f108bfa2546fa79333f8a731cfdd1dc xf86-input-evdev-2.7.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.7.2.tar.gz MD5: 4cde5a5ce2ae461b5c5a15dfead5018d xf86-input-evdev-2.7.2.tar.gz SHA1: 555ad8d257de29d757986e1b91178c38fcf15e2a xf86-input-evdev-2.7.2.tar.gz SHA256: 27af832f94e59a498cc1c96ce2c70e6a743014fbfdbf55e1ae70b899a39e6f5d xf86-input-evdev-2.7.2.tar.gz pgpFzB3RWFIbt.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Elographics on Fedora 17
On Fri, Aug 03, 2012 at 06:32:27AM -0700, Quentin Olson wrote: > I need the elographics input driver for Fedora 17. > > If someone wants to get me started on the work, I am glad to give it a try. you're probably best off following this instead: http://who-t.blogspot.com.au/2012/07/elographics-touchscreen-setup.html Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Custom input device configuration
On Wed, Aug 08, 2012 at 01:41:45AM -0700, johnfulgor wrote: > Hello all, > in a older version of the X server I had a InputDevice section in the > xorg.conf file for a special input device. > In my new system X uses auto configuration and xorg.conf.d. I've made a new > file in the xorg.conf.d and pasted the old InputDevice section in it, but it > seems to be ignored. The log file says does not even mention it. There is > something about the new auto-configuration that I do non understand. Can > someone help me? > Thank you. xorg.conf.d is _in addition_ to xorg.conf, so you can leave you previous configuration as-is. As for the file not being loaded, the most common reason for that is that it doesn't have the suffix ".conf". Anything else is guesswork though, you'd have to provide your actual configuration for us to figure out why it's not loading. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-evdev 2.7.3
Three bugfixes, the fix for 53168 fixes a regression introduced in 2.7.2. Peter Hutterer (4): Don't delete the device on ENODEV Link against libudev Fix broken ButtonMapping option (#53168) evdev 2.7.3 git tag: xf86-input-evdev-2.7.3 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.7.3.tar.bz2 MD5: f68920ce2921a88b4662acc972bf3a4a xf86-input-evdev-2.7.3.tar.bz2 SHA1: 57adaafd29d59b3685c923342717e767a0323474 xf86-input-evdev-2.7.3.tar.bz2 SHA256: eb389413602c3d28c44bbfab0477c98582f0e2f5be5f41986e58e93a033fa504 xf86-input-evdev-2.7.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.7.3.tar.gz MD5: 79692b6aad047fe27249710052128a56 xf86-input-evdev-2.7.3.tar.gz SHA1: 1757524edd815fc58e9d5965eb628598b8a45e8d xf86-input-evdev-2.7.3.tar.gz SHA256: 2208d886bf2b37f4341771c6120717e87ad275f03e4c5bda533e4bd37b63f91a xf86-input-evdev-2.7.3.tar.gz pgpiByxNCIWrs.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xvfb and xkb
On Fri, Aug 10, 2012 at 08:42:51AM -0700, Ashwin Chandra wrote: > I am using Xvfb to render an X session in memory. I am trying to use > setxkbmap to change the key layouts. I seem to have difficulty doing this > other than US key layout. There are no errors when calling “setxkbmap de” > (german language) however the keymap looks all wrong and certain modifier > keys like alt-gr don’t seem to work. I thought maybe I don’t have the right > keymaps compiled in but I did a diff of /usr/share/X11/xkb with a working > machine and it is the same. So I need some help figuring out how to debug > this problem. Setxkbmap doesn’t seem to have much info except the verbose > options telling me what it is setting. stab in the dark: you're not by any chance calling setxkbmap first and then other clients. If so, this would cause server regeneration and re-set anything done before. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xvfb and xkb
On Wed, Aug 15, 2012 at 10:20:13PM -0700, Ashwin Chandra wrote: > Thank you for responding Peter. > > I am not sure what you mean by calling setxkbmap first? > > Even if I embed the keymap to use in the InitKeyboardDeviceStruct() in the > Xvfb initiation process, same problem. oh, that answers the question then. servers regenerate when the last client disconnects, so if you do the following, the keymap is reset before anyone can use it: Xvfb & setxkbmap -layout de /* last (only) client disconnects, server regens with defaults */ xterm /* has the default keymap now */ > I wanted to know if there was a way to debug this and see exactly which > keymap file in a certain directory is being used? It looks like to me just > the keymap is somehow wrong. tbh, shoft of strace or gdb, I don't know Cheers, Peter > -----Original Message- > From: Peter Hutterer [mailto:peter.hutte...@who-t.net] > Sent: Wednesday, August 15, 2012 10:12 PM > To: Ashwin Chandra > Cc: xorg@lists.x.org > Subject: Re: Xvfb and xkb > > On Fri, Aug 10, 2012 at 08:42:51AM -0700, Ashwin Chandra wrote: > > I am using Xvfb to render an X session in memory. I am trying to use > > setxkbmap to change the key layouts. I seem to have difficulty doing > > this other than US key layout. There are no errors when calling “setxkbmap > > de” > > (german language) however the keymap looks all wrong and certain > > modifier keys like alt-gr don’t seem to work. I thought maybe I don’t > > have the right keymaps compiled in but I did a diff of > > /usr/share/X11/xkb with a working machine and it is the same. So I > > need some help figuring out how to debug this problem. Setxkbmap > > doesn’t seem to have much info except the verbose options telling me what > > it is setting. > > stab in the dark: you're not by any chance calling setxkbmap first and then > other clients. If so, this would cause server regeneration and re-set > anything done before. > > ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xvfb and xkb
On Thu, Aug 16, 2012 at 09:18:55AM -0700, Alan Coopersmith wrote: > On 08/16/12 09:14 AM, Ashwin Chandra wrote: > >After more searching on the web, a lot of people say the Xvfb and keymaps > >just don't work correctly (at least in older versions). > > > >Can anyone tell me if they have actually succeeded in getting Xvfb and > >setxkbmap working ? > > Since Xvfb has no keyboard devices to get input from, how would you tell > and why would you care? XTest should still work? could be a use-case, though I don't feel creative enough right now to think of one :) Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-elographics 1.4.1
Two fixes in this update. The fix fror 40870 now ensures that the touchscreen does come up as attached slave pointer by default (same behaviour as evdev and other drivers). And thanks to Søren's fix, the axis scaling now works too. Peter Hutterer (2): Don't force pInfo->flags to 0 (#40870) elographics 1.4.1 Søren Holm (1): Added correct scaling of axes. git tag: xf86-input-elographics-1.4.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-elographics-1.4.1.tar.bz2 MD5: b326f94647f4e81004aa15d74a14 xf86-input-elographics-1.4.1.tar.bz2 SHA1: 78455583a34ccd209edc1aba5538926df4faf47f xf86-input-elographics-1.4.1.tar.bz2 SHA256: a21af744d57f158e6dff9d60a68aaac46b8d726d602911940cb61f4d6bb2c6a4 xf86-input-elographics-1.4.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-elographics-1.4.1.tar.gz MD5: 1f1e440ff89f60aff10e09e88b9554ee xf86-input-elographics-1.4.1.tar.gz SHA1: 7ce87b545525bcbc3bad5ff8f0046766d17e76ef xf86-input-elographics-1.4.1.tar.gz SHA256: ef761fa32e7295c33e919f9c18f6be6671fe6117df771dde16da926ad41bda21 xf86-input-elographics-1.4.1.tar.gz pgpLxsAQu3x60.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Consistent handling of USB device buttons
On Mon, Aug 20, 2012 at 05:12:59AM +, Alex Dubov wrote: > Sorry for my previous mis-posting, there appears to be some problem with gmane > interface. > > There exist considerable number of hot-pluggable USB devices with helper > buttons > (cameras and headsets being the more prominent examples). The buttons in > question are recognized by evdev as USB HID interfaces, so in theory they are > considered as "supported". > > In practice, however, there are 2 common problems: > > 1. Buttons have session global effect and there's no easy, nor stable way to > limit their effect to a particular device. I don't understand this bit. can you paraphrase? > 2. Sometimes device buttons are recognized as "mice", rather than "keyboards" > and there's no much one can do with "mouse" buttons out of Xorg box (assorted > third party programs of varying breed and maintenance status notwithstanding). evdev will set up BTN_0...BTN_TASK as buttons on a device. anything else should be a keyboard. especially KEY_CAMERA should be a key. what specific device has the camera button set up as mouse button? Cheers, Peter > I tried to make some sense of the issue for myself, but it appears to be > impossible to get through untold scores of various user complains on the > inter-webs. :-) > > Can somebody point me at an information or discussions regarding the issues > above? After all, those devices are abundant and appear to work just fine even > on older windows xp, without any extraneous effort. > > It seems logical to me that USB buttons must represent a whole input device > class on their own, with appropriate events defined. I suppose, it won't be a > big deal to incorporate support for them into existing applications, because > the > need for such arrangement is long and widely recognized by anybody who tried > to > rely on such buttons on Linux. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Consistent handling of USB device buttons
On 21/08/12 18:19 , Xavier Bestel wrote: On Tue, 2012-08-21 at 13:16 +1000, Peter Hutterer wrote: 1. Buttons have session global effect and there's no easy, nor stable way to limit their effect to a particular device. I don't understand this bit. can you paraphrase? I guess he means if you have two webcams with a "mute" button, there's no way to associate the button with a particular webcam. To X11 it's just a global mute button. using XI2, you get the deviceid with each event, so that's easy enough to work around. whatever listens to it at the moment (e.g. gnome-settings-daemon) may not do this, but X certainly makes it possible. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Consistent handling of USB device buttons
On Tue, Aug 21, 2012 at 05:54:18AM +, Alex Dubov wrote: > Peter Hutterer who-t.net> writes: > > > > > > > 1. Buttons have session global effect and there's no easy, nor stable way > > > to limit their effect to a particular device. > > > > I don't understand this bit. can you paraphrase? > > For example, if I press a button on a headset and say it maps to > "XF86VolumeUp", how does the mixer application is supposed to know > which channel to adjust? I would expect it to only affect the headset, not > the "master" channel which is normally set to built-in audio card. use XI2 and deviceid in events, then you know that the volume up was hit on this particular device. clients may not make use of this right now, but the infrastructure is in place. > > evdev will set up BTN_0...BTN_TASK as buttons on a device. anything else > > should be a keyboard. especially KEY_CAMERA should be a key. what specific > > device has the camera button set up as mouse button? > > My most recent problem was with Plantronics Audio 648 USB headset (works on > XP out of the box). It's got 4 buttons ["call", "volume up", "volume down" > and "mic mute"], which for some reason are mapped by evdev to mouse buttons > [8, 3, 2, 1]. file this as bug and attach an evemu recording, I'll have a look at it. http://people.freedesktop.org/~whot/evemu/ Cheers, Peter > As per point 1 above, mouse button presses generated by headset seem > indistinguishable from normal mouse key presses when applications are > concerned (with expected funny results). ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Keyboard layout per device
On Sat, Aug 18, 2012 at 03:59:31PM +0200, Nicolas Vinot wrote: > Hi everybody, > > I usually use 3 keyboards layout : > — bepo, with a Typematrix or laptop integrated keyboard; > — azerty, to allow mates and colleagues to use my computer with a > better-known > layout on a standard USB keyboard; > — qwerty, for my Yubikey, a security token working only with this layout. > > I try to configure X to manage all those layouts and assign the right layout > to > each keyboard. > Here is my /etc/X11/xorg.conf.d/90-keyboard.conf : > http://pastebin.com/1e3qhKiT looks correct on a quick glance, but looking at the Xorg.log should tell you more about which option is set for which keyboard. Plus, make sure your desktop environment isn't overwriting your xorg.conf. If you use GNOME, that would be the case. Cheers, Peter > On my workstation (Typematrix + Yubikey + mate keyboard), I obtain the > following when I plug my keyboards : > > Assigned layout > Device PluggedTM YubiLogitech > 1 TM bépo OK > 2 Yubibépo OK qwerty OK > 3 Logitechazerty NOK azerty NOK azerty OK > 4 Yubiazerty NOK qwerty OK azerty OK > 5 TM bépo OK bépo NOKbépo NOK > > > On my laptop (integrated + Typematrix + Yubikey + mate keyboard) : > > Assigned layout > Device PluggedIntegrated TM Yubi > Logitech > 1 Integrated bépo OK > 2 TM bépo OK bépo OK > 3 Yubiqwerty NOK qwerty NOK qwerty OK > 4 Logitechqwerty NOK qwerty NOK qwerty OK > azerty OK > 5 Yubiqwerty NOK qwerty NOK qwerty OK > qwerty NOK > 6 TM bépo OK bépo OK bépo NOK > bépo NOK > > > This behaviour is very random and not predictable. > > Sometime the last plugged device layout is apply globally (case 6 on laptop) > sometime only on the last plugged device (case 5 on laptop). > > And I don't have the same behaviour on laptop and workstation (plug the yubi > reset all layout on laptop (case 3) but not on workstation (case 2)). > > Where I'm wrong on my configuration or where I misunderstand Xorg behaviour > or > configuration ? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: losing settings switching to and from virtual consoles
On Wed, Sep 26, 2012 at 12:18:17PM +1000, Peter Rayner wrote: > I have a wacom graphics tablet that I want to maintain in "absolute" > mode. I also frequently use virtual consoles. > This seems to lose the absolute setting. > Here is an example: > Within an emacs shell on the X display: > $ xsetwacom set "Wacom Bamboo 2FG 6x8 Finger touch" "Mode" "Absolute" > > xsetwacom get "Wacom Bamboo 2FG 6x8 Finger touch" "Mode" > Absolute > > > xsetwacom get "Wacom Bamboo 2FG 6x8 Finger touch" "Mode" > Relative > > I have the following in /etc/X11/xorg.conf.d/50-wacom.conf > Section "InputClass" > Identifier "Wacom class" > MatchProduct "Wacom|WACOM|WALTOP|Hanwang|PTK-540WL" > MatchDevicePath "/dev/input/event*" > Driver "wacom" > Option "Mode" "Absolute" > EndSection > > which doesn't seem to help. > I bet I'm missing something obvious here but would appreciate a pointer. which desktop environment are you running? GNOME had a bug where it would set touch devices to relative, fixed with GNOME_SETTINGS_DAEMON_3_4_0-21-ge40cb71 Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: AutoAddDevices and Adding Known Devices
On Sun, Sep 23, 2012 at 06:16:15AM -0700, Mark Depto wrote: > I am trying to manually configure a eGalax touchscreen using the evdev > driver which is currently working great. The problem I am having is that > allowing Xorg to autoconfigure the devices from udev results in ~100% cpu > utilization as soon as the touchscreen is touched with the USB keyboard and > mouse connected. I found a thread that this is a bug somewhere along the > lines, but the the workaround is to use the "Option AutoAddDevices false". I > have done this is and all is well, except for when I actually need to use a > mouse or the keyboard while developing my applications. With AutoAddDevices > set to off, I can't can't configure an InputClass to save my soul and I am > all out of ideas. Would you have any insight how I could manually tell Xorg > to use the keyboard and mouse when present? sigh. not to put too fine a point on it, but for virtually every issue you'll ever have you can find a thread somewhere that gives you bad advice. In general, stay away from sites that recommend disabling AutoAddDevices. AutoAddDevices disables input device hotplugging. Without hotplugging, none of the InputClass directives applies and you need to have a static section for every device. > Section "InputDevice" > Identifier "Keyboard0" > Driver "evdev" > Option "xkb_rules" "evdev" > Option "xkb_model" "pc105" > Option "xkb_layout" "us" > #Option "SendCoreEvents" "On" > EndSection This won't load anything because the Option Device is missing. Even if you add that section, if you unplug the device it'll just go away and never come back. Really, hotplugging is a feature that shouldn't be ignored these days. > Section "InputClass" > Identifier "MouseAll" > Driver "evdev" > MatchIsPointer "On" > MatchDevicePath "/dev/input/event*" > MatchProduct "Logitech Optical USB Mouse" > EndSection this won't be applied because the server won't see input devices. > # This works well but requires AutoAddDevices to be off > > Section "InputDevice" > Identifier "touchscreen0" > Driver "evdev" > #Option "CorePointer" > Option "Device" "/dev/input/touchscreen0" > Option "DeviceName" "touchscreen0" this option doesn't do anything. > #Option "Emulate3Buttons" > #Option "Emulate3Timeout" "50" > Option "SwapAxes" "On" > Option "InvertX" "On" > Option "InvertY" "On" > #Option "Rotate" "CW" > #Option "Calibration" "48 757 34 530" > #Option "Calibrate" "1" > #Option "SendCoreEvents" "On" > #Option "ReportingMode" "Raw" > EndSection first - do you have a udev rule that creates the touchscreen0 devices? by default these devices don't exist, so what is creating them? For anything else, I'd need to see your Xorg.log to get further. running evtest on the device may also give you a hint on what's going on that confuses the server. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Using xkbcomp for a specific device
On Sun, Sep 16, 2012 at 01:41:02PM -0700, Darren Hart wrote:
> I'm looking to modify the keysyms of a remote that presents as a usbhid
> device.
> I also have an HP wireless keyboard and mouse combination device that I do not
> wish to modify. I'm trying to accomplish this with a combination of setxkbmap
> and xkbcomp, using the "-i device_id" to xkbcomp to modify the keymap of only
> the remote. The problem: both devices get remapped.
>
> The following describes my system and the exact steps I've taken to try and
> remap the remote.
>
> $ xinput --list
> ⎡ Virtual core pointerid=2[master pointer (3)]
> ⎜ ↳ Virtual core XTEST pointer id=4[slave pointer
> (2)]
> ⎜ ↳ HOLTEK id=10 [slave pointer
> (2)]
> ⎜ ↳ HP HP Wireless Mini Keyboardid=11 [slave pointer
> (2)]
> ⎜ ↳ HP HP Wireless Mini Keyboardid=12 [slave pointer
> (2)]
> ⎣ Virtual core keyboard id=3[master keyboard (2)]
> ↳ Virtual core XTEST keyboard id=5[slave
> keyboard (3)]
> ↳ Power Buttonid=6[slave
> keyboard (3)]
> ↳ Video Bus id=7[slave
> keyboard (3)]
> ↳ Power Buttonid=8[slave
> keyboard (3)]
> ↳ HOLTEK id=9[slave
> keyboard (3)]
>
> In the list above, the HOLTEK is the remote (it sends both keyboard and mouse
> events). Yes it's horrible, but it's what I have and I'd like to make it
> work. The
> two entries for the HP Wireless Mini Keyboard correspond to the single USB
> receiver for the keyboard and mouse.
>
[...]
> The remote sends ctrl+p and ctrl+shift+p for pause and play. MythTV doesn't
> distinguish between the two, so I want to change the shifted P to another key,
> such as XF86AudioPlay. I'd also like to change the Backspace to Esc on the
> remote.
> I can make this work with the following script which I lifted from the MythTV
> wiki, and then modified:
>
> #!/bin/sh
> set -x
>
> remote_id=$(xinput list | sed -n 's/.*HOLTEK.*id=\([0-9]*\).*keyboard.*/\1/p')
> [ "$remote_id" ] || exit
>
> mkdir -p /tmp/xkb/symbols
> cat >/tmp/xkb/symbols/custom <<\EOF
> xkb_symbols "remote" {
> key {[ p,XF86AudioPlay ] };
> key { [ Escape, Escape ] };
> };
> EOF
>
> setxkbmap -device $remote_id -print | sed
> 's/\(xkb_symbols.*\)"/\1+custom(remote)"/' | xkbcomp -I/tmp/xkb -i $remote_id
> -synch - $DISPLAY 2>/dev/null
>
>
> Once run, the HP keyboard p and backspace keys continue to work. But once I
> run xev
> and press the play button, both the remote and the HP keyboard have been
> remapped.
> shift+p sends XF86AudioPlay and Backspace sends Esc on both devices. I
> checked that
> my version of xkbcomp contains the per-device patch by downloading the
> sources and
> checking the contents of xkbcomp.c:
[...]
> I also confirmed that if I send a bad device_id, the script displays X11 out
> of range
> errors, with the value to the operation being the hex value of the bogus
> device_id.
> No error is reported when I pass "9" (the device_id for the HOLTEK keyboard
> xinput
> assigns to the remote). If I use the HP Wireless xinput device IDs, the
> remapping does
> not take place.
>
> I can reset the devices to their original state using:
>
> $ setxkbmap -print | xkbcomp - $DISPLAY 2>/dev/null
>
> If I try to use "-i 11" or "-i 12" to reset just the HP Wireless keyboard,
> the change doesn't take effect.
>
> I am running on a 32 bit installation of Ubuntu 12.04 (Mythbuntu
> specifically). I've
> tried this in the XFCE desktop as well as with a .xinitrc with only an xterm
> running
> with the same results.
>
> Am I on the right track? Or is there another method I should be considering?
>
> Can anyone point to why xkbcomp appears to be sending the device_id, yet both
> the remote and the keyboard are being remapped?
not sure, this should work and testing it on my box here it does work
(tested on two keyboards). the 12.04 ubuntu X stack has a lot of input
patches that differ from upstream, so I suggest you try with an upstream X
server first.
Cheers,
Peter
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xorg-gtest 0.5.0
This release of xorg-gtest includes miscellaneous fixes to improve the API behaviour. Most notably, it greatly speeds up the time between tests by removing some unnecessary wait times. Olivier Fourdan (1): xserver: Pass given timeout value Peter Hutterer (33): aclocal: fill AS_IF with noop statements process: use fork(), not vfork() xserver: add GetVersion() to retrieve server version Require gtest-source-path to be absolute xserver: add getters and setters for config and log file xserver: add destructor to tear down the server Drop mentioning of uTouch-Evemu in comments, rename to evemu process: document that va_args for Start() must end with zero-length string Add Red Hat copyright notices process: add XORG_GTEST_CHILD_STDOUT environment variable xserver: use temporary variable for log file too xserver: if the logfile was created by TestStartup, remove it again xserver: don't push the program name into the argument list process: require NULL as last argument to Start() process: add state enum and GetState() xserver: add RemoveLogFile() test: add a self-check directory process: terminate the child if the parent dies test: add xserver test for logfile removal aclocal: set the proper include path for the default source path test: add xserver-test to gitignore device: move "device not found error down" device: only strcmp if EVIOCGNAME succeeds device: split device comparison into a helper function device: If we can't open the device, it's not the one we want device: if the device node is still empty when we need it, re-guess device: use inotify to wait for the device to appear Remove mention of "dummy" where it's not true anymore process: reduce wait time for process termination process: return if waitpid() fails xserver: don't sleep for a second, 100us is enough process: fix compiler warning xorg-gtest 0.5.0 git tag: xorg-gtest-0.5.0 http://xorg.freedesktop.org/archive/individual/test/xorg-gtest-0.5.0.tar.bz2 MD5: bcd34ec5e5dea25687b01b110fccdcae xorg-gtest-0.5.0.tar.bz2 SHA1: 45a859cd94da7af9c93ee9257967c65582f3af6a xorg-gtest-0.5.0.tar.bz2 SHA256: b7887b38f2f51e56b1cd2e9390e2f2bcb86cf948c5755079b2b4690212393782 xorg-gtest-0.5.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/test/xorg-gtest-0.5.0.tar.gz MD5: 408cb01cfdfdbe4c637d15d234e5e488 xorg-gtest-0.5.0.tar.gz SHA1: 1723560e77bbfa28d11c952e319ef66303b577dd xorg-gtest-0.5.0.tar.gz SHA256: b3802da4fc338cd56ef091837ae7de29f5acc0d47395e698e14dc56a3e0b94e2 xorg-gtest-0.5.0.tar.gz pgp9TU6qEDnII.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xorg-gtest 0.6.0
xorg-gtest 0.6.0 is now available. xorg-gtest is a set of classes on top of googletest to make writing integration tests easier. A bunch of features were merged in this cycle: - googletest source files were imported, so there is no need to build against a locally installed version of googletest - WaitForDevice() was improved to work on it's own without the need for setting event masks manually - tests should use XORG_TESTCASE() for test case descriptions to get standardised prints of test cases - a default XIO error handler was added. Test cases that lose the display connection will now throw an exception instead of just calling exit(1) - WaitForConnections() was deprecated as we now always wait for the server to start up and accept connections Daniel Martin (2): xserver: use SIGUSR1 to wait for XServer startup Deprecate WaitForConnections() Peter Hutterer (28): Drop compat headers include: fix doxygen warning Bump to 0.5.99 Import googletest's fused-src files Fix up build system to use the googletest import build process: if termination fails, the state must not be TERMINATED test: rename two process tests test: add helper program for process termination issue xserver: don't throw exceptions on failed startup test: add test-case for starting servers process: on termination, check if the process exited and set the error code process: wait for SIGCHLD instead of busy looping test: add test for termination exit status test/process-test: add test for starting the same process object multiple times test/process-test: prefix TESTCASE with newline in debugging output xserver: use a default timout for 1s for Terminate() and Kill() tests: drop gtest.h include, xorg-gtest.h pulls it in anyway include: add XORG_TESTCASE() macro for standardised printing of descriptions include: add inclusion guards to xorg-gtest.h xserver: set the hierarchy mask before WaitForDevice xserver: query device list before waiting examples: fix compiler warning examples: fix compiler warning tests: drop gtest.h include, xorg-gtest.h pulls it in anyway include: add XORG_TESTCASE() macro for standardised printing of descriptions include: add inclusion guards to xorg-gtest.h xserver: add default X IO error handler xorg-gtest 0.6.0 git tag: xorg-gtest-0.6.0 http://xorg.freedesktop.org/archive/individual/test/xorg-gtest-0.6.0.tar.bz2 MD5: 03840e2f77da5b7f44e99f6ebd8c310c xorg-gtest-0.6.0.tar.bz2 SHA1: cb239bdc9200094da70a7a4227552ad13651d461 xorg-gtest-0.6.0.tar.bz2 SHA256: f6a3542c15a490970d5ba4d1f65e15e662c307de35f4c6e605280a17f9f6d9e6 xorg-gtest-0.6.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/test/xorg-gtest-0.6.0.tar.gz MD5: 090f9f5b7276282ca6d10c805ebdc699 xorg-gtest-0.6.0.tar.gz SHA1: beb852e8d1a80059e9183f94efaa831d290f8122 xorg-gtest-0.6.0.tar.gz SHA256: 495f70e90256e49317e68f82fcae760f9d481d206573c9d933e0f6a8c8652005 xorg-gtest-0.6.0.tar.gz pgpdbgt3i5VJx.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Mouse wheel acceleration?
On Thu, Nov 15, 2012 at 08:51:23AM +1100, Will Rouesnel wrote: >Is there any word on what happened to the efforts to support mouse >wheel acceleration? It doesn't seem to be implemented in Xserver 1.12, >and I can find no reference to it online beyond the initial posts on >the Xorg-devel mailing list ( >http://lists.x.org/archives/xorg-devel/2010-September/012517.html) >Is it currently under any active development? no-one is working on it afaik, last patches (sep 2010) are here: https://bugs.freedesktop.org/show_bug.cgi?id=29905 given that we have smooth scrolling now, IMO mouse wheel acceleration should be controlled more by the client side than the server, where it is harder to get right, tricky to configure, and may not even work consistently across devices. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Mouse wheel acceleration?
On 15/11/12 14:50 , Will Rouesnel wrote: On Thu 15 Nov 2012 11:43:17 EST, Peter Hutterer wrote: On Thu, Nov 15, 2012 at 08:51:23AM +1100, Will Rouesnel wrote: Is there any word on what happened to the efforts to support mouse wheel acceleration? It doesn't seem to be implemented in Xserver 1.12, and I can find no reference to it online beyond the initial posts on the Xorg-devel mailing list ( http://lists.x.org/archives/xorg-devel/2010-September/012517.html) Is it currently under any active development? no-one is working on it afaik, last patches (sep 2010) are here: https://bugs.freedesktop.org/show_bug.cgi?id=29905 given that we have smooth scrolling now, IMO mouse wheel acceleration should be controlled more by the client side than the server, where it is harder to get right, tricky to configure, and may not even work consistently across devices. Cheers, Peter This doesn't quite make sense to me. Pointer acceleration in X isn't a client specific function, and the mouse wheel is - ultimately - just another pointer axis, with smooth scrolling expressing that properly now. Surely with proper mouse wheel axes now, it would simply be a matter of letting a pointer acceleration profile be defined for those axes? pointer movement is application-independent, mouse wheels (and thus scrolling) not. depending on where you scroll, nothing may happen, you may scroll a line at a time, a word at a time, a page at a time, etc. Putting any acceleration into scrolling obfuscates the physical information from the device, quite likely to the detriment of the applications that want to use it for their own acceleration methods. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Where are xmodmap settings saved?
On Fri, Nov 16, 2012 at 03:12:51PM +0100, José Luis Lafuente wrote: > I created my own keyboard layout and loaded it with xmodmap .Xmodmap. > Now I want to go back to a default layout, I deleted .Xmodmap, but > after a reboot the layout defined with xmodmap is still present. What > files is modifying xmodmap? What did xmodmap to save the layout that > makes it persistent? xmodmap doesn't save anything, it merely applies settings to the running server. if the settings are still there, this means that either your changes were identical to the default layout anyways or there is a xmodmap process being run with the changes once the server is started. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: cirque smartcat touchpad
On Sat, Nov 17, 2012 at 04:37:49AM -0800, Sebastian Glita wrote: > While trying a simple search whether Xorg supports this device: > > > http://www.cirque.com/desktoptouchpad/productsandorders/smartcat.aspx > > the 4-button USB touchpad, probably with "synaptics" driver, I couldn't find > any RECENT (2011-2012) discussion. > > > Is it recognized with the latest sources from cgit.freedesktop.org (mouse, > evdev, synaptics)? the main question is whether it is supported by the kernel. X hardly deals with touchpads directly these days, it's handled by the (linux) kernel and we see the evdev interface. So you need to first check if the kernel supports it. > Do the 4-buttons work? The scroll? yes, likely, if the kernel supports the touchpad. > Do the "advanced gestures" work? no, only scrolling. gestures are implemented on the client-side, so these must be implemented by your client-stack (which may already do so, e.g. newer GTK and Unity) Cheers, Peter > Thank s. > > > P.S.: The description from manufacturer: > > Functionality > * Multi-finger Advanced Gestures available: scroll, zoom, rotate and more > * Execute, browse at the touch of a finger > * Zoom reduces or enlarges Office documents > * Scroll moves horizontally & vertically > * Right tap mimics a mouse right-click > * GlideExtend® virtually eliminates the edge of the pad when dragging > * Adjustable sounds, speed, sensitivity and orientation > Product Highlights > * Extra-large touch surface > * Easy-to-find textured "right" click area > * One-touch scroll, zoom and surf > * Three (3) mechanical buttons supported > * Withstands spills and abuse > * Easy PS/2 or USB connectivity > > P.S.: A description from a seller website: > > Product Features > > * Intuitive design, simply glide finger on surface. > * One-Touch Scroll and Zoom > * Ability to go from fast screen movement to pixelpoint control > * Activate vertical / horizontal scrolling at a touch of a finger > > > Technical Details > USB Keyboard > ___ > xorg@lists.x.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.x.org/mailman/listinfo/xorg > Your subscription address: peter.hutte...@who-t.net > ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XI2 pointer emulation in more detail
On Sat, Nov 17, 2012 at 10:39:29AM -0600, Daniel Drake wrote: > Hi, > > Thanks for all the informative blog posts such as this one: > http://who-t.blogspot.com/2011/12/multitouch-in-x-pointer-emulation.html > > I'm trying to get my head around pointer emulation and touch-pointer > interaction in a bit more detail. Would appreciate any guidance or > followup posts :) > > This is all with xserver-1.13.0 patched with: > Sync TouchListener memory allocation with population in TouchSetupListeners() > Xi: Don't check for TOUCH_END, it's never set > Xi: don't deliver TouchEnd to a client waiting for TouchBegin (#55738) > Xi: Set modifier mask on touch events > Xi: Update the device after delivering the emulated pointer event(#56558) > remove init_event > Update the MD's position when a touch event is received > Don't use GetTouchEvents when replaying events > Don't use GetTouchEvents in EmitTouchEnd > Simplify GetTouchEvents > > Following the blog post, writing a simple non-touch XI2 listening app, > quickly touching and releasing the screen generates: motion, button > press, button release. All have XIPointerEmulated set. > > Now, when I make the app listen for touch events, the sequence > changes, to: Motion (with XIPointerEmulated), TouchBegin, TouchEnd. > The fact I received a Motion event seems in conflict with what is > written: "if your client selects for both touch and pointer events on > a window, you will never see the emulated pointer events." > > Is this a bug? Here is the test app: > http://dev.laptop.org/~dsd/20121117/xitouch.c Right, what happens is simple: for pointer-emulating touches, we need to move the cursor. That requires sending motion events. This should probably be fixed, we need a filter on the first client selecting for TouchUpdate _or_ MotionNotify and then discard the event if it's the former (and pretend we delivered). right now, we don't have that filter. but tbh, your app should not get too confused by this, it is just a state-less motion event after all. > I couldn't find a mention of the general idea of the event stream > changing when touch events are/aren't listened to in XI2proto.txt - am > I missing something? (If not, I'll send a patch, once my understanding > is complete) I can't remember if we've written it down, but the consensus was that if you're listening to touch events, you don't get pointer emulated events. one reason is that you can't associate touch points and pointer emulated events easily, the other obviously that if you're already listening for touch events, why would you need the pointer events. > My next area of doubt is how touchscreen interaction should interact > with the mouse cursor. > > In GNOME (fallback), when I place the mouse cursor inside a window, > and then touch the screen in another part of the same window, the > touch is registered as expected but the mouse cursor stays put. > > This behaviour changes when I add a second window into the mix. If I > place the mouse cursor in one window, then touch into another window, > the mouse cursor jumps to the touch point. > > Is there a reason for this difference in behaviour? no, this sounds like a bug. pointer emulation behaviour should be that only the first emulating touchpoint changes the pointer position, with subsequent touches not emulating. and a touchpoint is only emulating if there is no other touch point on that device when it starts. I might need more details though, how are you placing the pointer? with a mouse? Cheers, Peter > In Sugar, even when touching within the same window where the mouse > pointer is, the mouse pointer always jumps. This doesn't feel like the > right behaviour for the user. The difference from GNOME may be related > to the fact that we have some grabs set up, and we listen for touches, > for our touch gesture implementation. > > Furthermore, this pointer-jumping behaviour is giving us problems, > both in Sugar and GNOME. For example, position a window's "close" > button directly on top of another window with a hover-sensitive > widget. Touch-press the close button on the on-top window. The on-top > window gets closed, and the implicit move of the mouse cursor now > triggers the hover-event on the widget in the window below. This > results in a strange touchscreen user experience and a variety of > problems: > http://bugs.sugarlabs.org/ticket/4068 > > Any thoughts/comments much appreciated. > > Thanks > Daniel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XI2 pointer emulation in more detail
please don't cut the email out completely, it's hard to reference to the relevant sections. On Tue, Nov 20, 2012 at 09:02:16AM -0600, Daniel Drake wrote: > On Mon, Nov 19, 2012 at 12:17 AM, Peter Hutterer > wrote: > > no, this sounds like a bug. pointer emulation behaviour should be that only > > the first emulating touchpoint changes the pointer position, with subsequent > > touches not emulating. and a touchpoint is only emulating if there is no > > other touch point on that device when it starts. > > > > I might need more details though, how are you placing the pointer? with > > a mouse? > > Yes, the pointer is being placed with a mouse. The OLPC XO laptop in > question has both a touchscreen and a touchpad. > > In these tests I am only touching the screen with 1 finger at any one > time. I think your reply might have included multi-touch > considerations (what is a "subsequent touch"?), but I'm not venturing > there yet. in this context it meant that a touch emulates pointer events if it is the first touch at TouchBegin time. that touch continues to emulate until TouchEnd, regardless of any other touches. however, if you put one finger down (emulating), a second finger down (not-emulating), then lift the first finger and put it down again, that same finger won't emulate pointer events now (as the second finger is still down) > I think you may be suggesting here that having screen touches move the > mouse cursor is by design. Unfortunately that leads to the awkward > hover behaviour and confusing touchscreen user experience outlined in > my original mail. Is there anything on the horizon that might improve > this? _where_ you touch is irrelevant, and in fact we decide on whether a touch point is emulating well before we look at where to deliver the touchpoint. I've read the http://bugs.sugarlabs.org/ticket/4068 report and the real issue here appears to be that the sprite isn't updated to the new position on the brief touch you described. Thomas Jaeger's "Update the MD's position when a touch event is received" should have fixed that part though I noticed you have that patch in the tree already and the issue still occurs. I'd appreciate it if you could write up a simple test case for this so I can reproduce this. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Mousepad - how to disable tapping?
On Wed, Nov 21, 2012 at 10:48:05AM +0100, Kamil Jońca wrote: > > I have got something like: > http://www.amazon.co.uk/Perixx-PERIPAD-501-86x75x11mm-Industrial-Professional/dp/B001CX85I8 > > with lsusb it shows as: > --8<---cut here---start->8--- > Bus 001 Device 092: ID 099a:a002 Zippy Technology Corp. > --8<---cut here---end--->8--- > > Relevant xorg logs are > --8<---cut here---start->8--- > [1291767.832] (II) config/udev: Adding input device Mouse Pad > (/dev/input/mouse1) > [1291767.832] (**) Mouse Pad: Applying InputClass "mousepad" > [1291767.832] (II) No input driver specified, ignoring this device. > [1291767.832] (II) This device may have been added with another device file. > [1291767.837] (II) config/udev: Adding input device Mouse Pad > (/dev/input/event7) > [1291767.837] (**) Mouse Pad: Applying InputClass "evdev pointer catchall" > [1291767.837] (**) Mouse Pad: Applying InputClass "mousepad" > [1291767.837] (**) Mouse Pad: Applying InputClass "evdev pointer catchall" > [1291767.837] (II) Using input driver 'evdev' for 'Mouse Pad' > [1291767.837] (**) Mouse Pad: always reports core events > [1291767.837] (**) evdev: Mouse Pad: Device: "/dev/input/event7" > [1291767.837] (--) evdev: Mouse Pad: Vendor 0x99a Product 0xa002 > [1291767.837] (--) evdev: Mouse Pad: Found 3 mouse buttons > [1291767.837] (--) evdev: Mouse Pad: Found scroll wheel(s) > [1291767.837] (--) evdev: Mouse Pad: Found relative axes > [1291767.837] (--) evdev: Mouse Pad: Found x and y relative axes > [1291767.838] (II) evdev: Mouse Pad: Configuring as mouse > [1291767.838] (II) evdev: Mouse Pad: Adding scrollwheel support > [1291767.838] (**) Option "Emulate3Buttons" "on" > [1291767.838] (**) evdev: Mouse Pad: YAxisMapping: buttons 4 and 5 > [1291767.838] (**) evdev: Mouse Pad: EmulateWheelButton: 4, > EmulateWheelInertia: 10, EmulateWheelTimeout: 200 > [1291767.838] (**) Option "config_info" > "udev:/sys/devices/pci:00/:00:02.1/usb1/1-4/1-4.2/1-4.2:1.0/input/input70/event7" > [1291767.838] (II) XINPUT: Adding extended input device "Mouse Pad" (type: > MOUSE, id 8) > [1291767.838] (II) evdev: Mouse Pad: initialized for relative axes. > [1291767.838] (**) Mouse Pad: (accel) keeping acceleration scheme 1 > [1291767.838] (**) Mouse Pad: (accel) acceleration profile 0 > [1291767.839] (**) Mouse Pad: (accel) acceleration factor: 2.000 > [1291767.839] (**) Mouse Pad: (accel) acceleration threshold: 4 > --8<---cut here---end--->8--- > > > I added Input section for it: > > --8<---cut here---start->8--- > Section "InputClass" > Identifier "mousepad" > MatchProduct "Mouse Pad" > Option "Emulate3Buttons" "on" > EndSection > --8<---cut here---end--->8--- > > And now everything works fine except two things: > 1. Cannot disable tapping. I tried to use "synaptic" driver for this > device, but got only something like "cannot determine protocol". if you look at the axis and buttons found, this device looks like a generic mouse with two relative axes, a scroll wheel and 3 buttons. most touchpads these days have this mode, and while in this mode they implement tapping, scrolling etc in the firmware. The solution here is to get the kernel to initialise the device into a raw mode, where we get the actual events from the touchpad and the features can be controlled by the X input module. > 2. How can I tune acceleration? xinput list-props, all properties prefixed with Device Accel Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: cirque smartcat touchpad
On Thu, Nov 22, 2012 at 08:50:35AM -0800, Sebastian Glita wrote: > > the main question is whether it is supported by the kernel. X hardly deals > > with touchpads directly these days, it's handled by the (linux) kernel and > > > we see the evdev interface. So you need to first check if the kernel > > supports it. > > Hmm... There seems to be no indication in synaptics USB kernel driver about > "easycat/smartcat" (drivers/input/mouse). > > Next "roundabout" question would be, given the FAQ page says an "alike" OS > works: > > "... and the USB Cirque Smart Cat® (GP410U-) ... are recommended Cirque > trackpad for > the Macintosh OS. > * Mac OS 8.5 or later is required for both of these trackpads. > * Mac OS X or later is required for the vertical scrolling feature." > > how far can I assume linux kernel would recognize it too? I know that whereas > usually linux isn't specified, but mac is, there is a good chance a device > would work with both mac and linux... the two are unrelated. it may work, it may not, sorry. Generally the older a device, the higher the chance of it working but I really don't know in this case. Cheers, Peter > >> Do the 4-buttons work? The scroll? > > > > yes, likely, if the kernel supports the touchpad. > > > Actually, clicking, tapping and scrolling are enough for me. > > Thank s. > > > > >> Do the "advanced gestures" work? > > > > no, only scrolling. gestures are implemented on the client-side, so these > > must be implemented by your client-stack (which may already do so, e.g. > > newer GTK and Unity) > > > > Cheers, > > Peter > > > > ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xf86-input-synaptics: Secondary mouse button isn't recognized
On Sat, Nov 24, 2012 at 12:52:54AM +0100, Karol Babioch wrote: > Hi, > > I'm not entirely sure whether this is the right mailing list, however I > couldn't find a more specific one, so hopefully I'm not too wrong. > > It's the first time I run into trouble with synaptics, so probably I > should thank you guys for the great work you are doing here. > > The touchpad I've got trouble with is part of a Sony laptop. The > touchpad is "special" in that that there aren't any visible buttons. The > touchpad itself is a "plate" and there are physical clickable buttons in > the left bottom and right bottom beneath the "plate", which correspond > to the normal "left" and "right" buttons. > > The "left" one gets recognized just fine and is usable within X. However > the right one isn't recognized at all :(. please provide your Xorg.log. this should be a clickpad, the matching property should be set and the right button should be enabled in software. not sure why it isn't in your case, but without the log it's hard to say whether it's a bug or it's not recognised properly. > xinput repots the following: > > [andreas@sve input6]$ xinput list-props 12 | grep "Capabilities" > Synaptics Capabilities (298): 1, 0, 0, 1, 1, 1, 1 > > The version of xf86-input-synaptics on my system is 1.6.2. > > I have found some advices for getting the "plate" type of touchpad > working. However, I think they don't apply here, because in my case > there seem to be real physical buttons beneath the "plate", whereas the > advices seem to assume that you've got no physical buttons at all. I don't think that there are the physical buttons, the capabilities property only describes a left button so my guess is that the right button is software-emulated based on the finger position. Cheers, Peter > > I'm not too familiar with synaptics, so I'm not sure what else you would > like to have in order to narrow this down. Just let me know. I also > should be capable of applying some patches and recompiling the whole > thing, if necessary. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xorg-gtest 0.7.0
xorg-gtest 0.7.0 is now available. Improvements since 0.6.0: - XORG_GTEST_XSERVER_KEEPALIVE keeps the test server running after a test finishes to allow for further debugging - XORG_GTEST_USE_VALGRIND starts the server under valgrind - miscellaneous fixes, including slightly better documentation Also, no more .gz tarballs. Keith Packard (1): Fix CFLAGS to find correct header files Peter Hutterer (34): xserver: increase timout to 3 seconds process: split Fork() and Start() into (optionally) two calls xserver: use new fork handling for signal masks xserver: add XORG_GTEST_XSERVER_KEEPALIVE environment variable xserver: shut up compiler warning test: add process-test-helper to gitignore xorg-gtest-main: fix trailing whitespace Expand on the default 'failed to open connection to display' error Drop .gz tarballs, bz2 is enough examples: use abs_top_srcdir to link to the config file test: exit(0) the xserver test after forking xserver: change Start() to be virtual xserver: make second arg to SetOption() default to "" xserver: add RemoveOption Move default log/config setting back to environment Make default log path configurable xserver: ignore SIGUSR1 in the parent after server startup examples: rename xorg-gtest-example to indicate it's an Environment example examples: add test examples for manual XServer control test: change USB mouse recordings file to dist_noinst_DATA test: conf paths must be absolute gtest: add gtest-spi.h header xserver: install default X error handler Add support for starting a process through valgrind xserver: default to -1/-1 for extension/opcode test: unset environment variable after use test: wait a bit for the server to finish test: restore error handler after test examples: Document two variables to silence doxygen process: drop a few SCOPED_TRACE process: if the wait fails because the child is still running, reset errno xserver: increase default Terminate/Kill timeout to 2 seconds xserver: usecs are usecs, not millis xorg-gtest 0.7.0 git tag: xorg-gtest-0.7.0 http://xorg.freedesktop.org/archive/individual/test/xorg-gtest-0.7.0.tar.bz2 MD5: c42a25bb8f10816cd283689f7d66460e xorg-gtest-0.7.0.tar.bz2 SHA1: b6d515f1d884b6f8ffd80f8187a769a807ddc1f8 xorg-gtest-0.7.0.tar.bz2 SHA256: bd7fbb84d6046d70564c002a5f82d9628ad1fa2c2087738788bcdf292e03e68e xorg-gtest-0.7.0.tar.bz2 pgpnQsIOyYpwp.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] inputproto 2.2.99.1
I forgot to actually tag and release this, so here it is - the first snapshot for XI 2.3. The new addition are pointer barrier events and the ability to release pointers after they were constrained by a barrier. Daniel Martin (3): specs: XI2: Fix typos specs: XI2: Rename AxisClass to ValuatorClass specs: XI2: Fix mods in XIPassive(Un)GrabDevice Jasper St. Pierre (1): Add support for pointer barrier events Peter Hutterer (6): Fix two typos in spec/comments XI2proto: spec formatting fix Fix typo in comment Claim support for XI 2.3 inputproto 2.2.99.1 specs: removing a device results in a BarrierLeave event Ran Benita (2): specs: XI2: make event/request name formatting consistent specs: XI2: add titles to requests/events and show them in TOC git tag: inputproto-2.2.99.1 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.2.99.1.tar.bz2 MD5: 04aa47443a8ad0388eb2bf3cd3869926 inputproto-2.2.99.1.tar.bz2 SHA1: 000585c0f2fec849f9f0ac9ce74a04a905a49fab inputproto-2.2.99.1.tar.bz2 SHA256: 2046e3edef74c56362be2bebda1c9129e83dc13aa1943d624c6ee76af00e15a2 inputproto-2.2.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.2.99.1.tar.gz MD5: b6c80abbe55ef842b5268222531cf903 inputproto-2.2.99.1.tar.gz SHA1: 37c358ecbb56a84947252c9738b3aac0682c1b16 inputproto-2.2.99.1.tar.gz SHA256: 1859ca71ff570c463381d0f4544e5b123e2fd91af52398214f8ba2e04d474def inputproto-2.2.99.1.tar.gz pgpBHeXPcUdkN.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] libXi 1.6.99.1
This snapshot adds client support for XI 2.3's pointer barrier events and releases. Jasper St. Pierre (1): Add support for pointer barrier events Peter Hutterer (7): man: fix formatting issues in XGetDeviceControl(3) man: add generation of missing man pages for XIGrabTouchBegin Fix compiler warnings Fix const compiler warnings Bump to 1.6.99 man: add man-page for XIBarrierReleasePointer libXi 1.6.99.1 git tag: libXi-1.6.99.1 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.6.99.1.tar.bz2 MD5: e8dcd93401e7d9321ce26c1b92ee84d6 libXi-1.6.99.1.tar.bz2 SHA1: 911811d7f8b502178bbbea5fa74325005b536903 libXi-1.6.99.1.tar.bz2 SHA256: 0642e6eef2e40c37cea79a22ab5f0cd3e48a57526cf1ac1128cda9369a449292 libXi-1.6.99.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.6.99.1.tar.gz MD5: 0340ab5fe94e42b7002f8058d3986195 libXi-1.6.99.1.tar.gz SHA1: 6a8f7e494225ebd1882765b9aa26a12dc7f6e0e1 libXi-1.6.99.1.tar.gz SHA256: 254af6beb7be37983ce4dbe98318417ff3c0e7a7fcaf3c5ce81d35e1e74aed7a libXi-1.6.99.1.tar.gz pgpds888uT7bX.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
