Need help with M$ touchmouse
Peter Hutterer
peter.hutterer at who-t.net
Sat Dec 6 03:14:12 PST 2014
On 6/12/2014 12:33 , Gene Heskett wrote:
> On Friday 05 December 2014 18:46:58 Peter Hutterer did opine
> And Gene did reply:
>> On 6/12/2014 01:56 , Gene Heskett wrote:
>>> On Thursday 04 December 2014 23:03:38 Peter Hutterer did opine
>>>
>>> And Gene did reply:
>>>> On Thu, Dec 04, 2014 at 09:43:44PM -0500, Gene Heskett wrote:
>>>>> On Thursday 04 December 2014 16:18:16 Peter Hutterer did opine
>>>>>
>>>>> And Gene did reply:
>>>>>> On Thu, Dec 04, 2014 at 01:23:49PM -0500, Gene Heskett wrote:
>>>>>>> Greetings all;
>>>>>>>
>>>>>>> I have a wireless M$ Explorer Touchmouse, and the touch pad is
>>>>>>> buggier than a 10 day old carcass.
>>>>>>>
>>>>>>> Specifically, the side scrolling is driving me crazy, and its not
>>>>>>> a long trip. ;)
>>>>>>>
>>>>>>> When it works, its 20x more sensitive sideways than vertically,
>>>>>>> and I can't get my fingers far enough away from the pad to stop
>>>>>>> its crazy behavior, and still rest them in a comfy location for
>>>>>>> button pushing.
>>>>>>>
>>>>>>> Is there anything I can put in an /etc/X11 file that will shut
>>>>>>> the side scroll function off, but leave the vertical finger
>>>>>>> drags working?
>>>>>>
>>>>>> attach an evemu recording and your xorg.log to a bug please. I
>>>>>> don't have a recording for this one yet so it's hard to tell.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Peter
>>>>>
>>>>> First off Peter, evemu is not 'locate'able. And I'm not sure you
>>>>> want the current Xorg.0.log in your mailbox as its north of 179
>>>>> megabytes.
>>>>
>>>> you could have restarted X, or started another session for a fresh
>>>> log file. or cut down the thousands of lines of errors which is
>>>> likely what 99% of the log file are if it grows to that size in a
>>>> week.
>>>>
>>>>> I even sicc'd synaptic to find it in the ubuntu repo, and came up
>>>>> dry there too.
>>>>
>>>> evemu shows up as second link on google for me:
>>>> http://www.freedesktop.org/wiki/Evemu/
>>>>
>>>> but tbh, if you're on a 4 year old box you're pretty much on your
>>>> own, sorry. there may have been kernel fixes since, there may have
>>>> been evdev fixes since, etc.
>>>
>>> I do occsionally build a fresher kernel because the default kernel
>>> for this particular install, an rtai kit on top of 2.6.32-123, has
>>> no PAE and there's 8Gb in this box. Running the OEM kernel only
>>> sees 3Gb of that, and I'm a gigabyte into swap in 24hrs.
>>>
>>> So the presently running kernel is a 3.16.0. 32 bit with PAE.
>>> Hasn't touched swap in months.
>>>
>>> Nest, that link 3rd line is bogus, needs an ".sh" tagged onto the
>>> ./autogen script cli invocation.
>>>
>>> The autogen output this to the screen:
>>> gene at coyote:/usr/src/evemu$ ./autogen.sh --prefix=/usr
>>> autoreconf: Entering directory `.'
>>> autoreconf: configure.ac: not using Gettext
>>> autoreconf: running: aclocal
>>> autoreconf: configure.ac: tracing
>>> autoreconf: configure.ac: creating directory config-aux
>>> autoreconf: running: libtoolize --install --copy
>>> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR,
>>> `config-aux'. libtoolize: copying file `config-aux/config.guess'
>>> libtoolize: copying file `config-aux/config.sub'
>>> libtoolize: copying file `config-aux/install-sh'
>>> libtoolize: copying file `config-aux/ltmain.sh'
>>> libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to
>>> configure.ac and
>>> libtoolize: rerunning libtoolize, to keep the correct libtool macros
>>> in- tree.
>>> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in
>>> Makefile.am. autoreconf: running: /usr/bin/autoconf
>>> autoreconf: running: /usr/bin/autoheader
>>> autoreconf: running: automake --add-missing --copy --no-force
>>> configure.ac:12: installing `config-aux/missing'
>>> python/Makefile.am:20: installing `config-aux/py-compile'
>>> src/Makefile.am: installing `config-aux/depcomp'
>>> autoreconf: Leaving directory `.'
>>>
>>> But make cannot find the makefile, and indeed there was not one
>>> created. The INSTALL inserts a ./configure step in the sequence, and
>>> that bails out for lack of:
>>>
>>> checking pkg-config is at least version 0.9.0... yes
>>> checking for LIBEVDEV... configure: error: Package requirements
>>> (libevdev
>>>
>>>> = 1.2.99.902) were not met:
>>> No package 'libevdev' found
>>>
>>> Consider adjusting the PKG_CONFIG_PATH environment variable if you
>>> installed software in a non-standard prefix.
>>>
>>> Alternatively, you may set the environment variables LIBEVDEV_CFLAGS
>>> and LIBEVDEV_LIBS to avoid the need to call pkg-config.
>>> See the pkg-config man page for more details.
>>>
>>> Apparently I'll need a git URL to get it and install it? Amazingly
>>> that gets zero hits on google. You have found the ultimate google
>>> non-entity! That has NEVER happened before.
>>>
>>> So you see what I need to do above and I am waiting, with "baited"
>>> breath for further instruction. ;-)
>>
>> http://who-t.blogspot.com.au/2014/05/configure-fails-with-no-package-fo
>> o.html
>>
>> Cheers,
>> Peter
>
> That is quite helpful. But this system hasn't such a critter. So I
> pulled in the tarball for libevdev-1.3, but nothing I can do with a --
> with-docs, or even spelling it out, seems to convince it to build the docs
> too.
>
> End of configure bailout
> configure: WARNING: unrecognized options: --with-documentation
>
> Prefix /usr/local
> Libdir ${exec_prefix}/lib
>
> Build documentation no
> Build unit-tests no
> Enable profiling no
> Static library symbol check yes
>
> a --help doesn't show it as an option either. And that does puzzle me
> because the --help on most configure scripts is 2 or 3 screens full.
please read up on a few tutorials on how to build software from source
and how to interpret the configure output. none of this here is special,
we just use standard automake stuff.
fwiw, the documentation is just doxygen, you can read it online on the
libevdev website, no need to build it locally.
Cheers,
Peter
More information about the xorg
mailing list