Problem solved
when I changed so names from
libudev.so
libudev.so.1 -> libudev.so.1.0.1
libudev.so.1.0.1 -> libudev.so.1.5.1
libudev.so.1.5.1 -> libudev.so.1.6.0
libudev.so.1.6.0 -> libudev.so.1.6.4
libudev.so.1.6.4 -> libudev.so
to
libudev.so
libudev.so.1 -> libudev.so.1.0.1
libudev.so.1.0.1 -> libudev.so.1.5.1
libudev.so.1.5.1 -> libudev.so.1.5.2
libudev.so.1.5.2 -> libudev.so.1.6.0
libudev.so.1.6.0 -> libudev.so.1.6.4
libudev.so.1.6.4 -> libudev.so
though for original libudev from arch has
libudev.so -> libudev.so.1.6.4
libudev.so.1 -> libudev.so.1.6.4
libudev.so.1.6.4
and that doesn't work for me
Anyone can clear up naming conventions of so-names?
Maybe correct should be
libudev.so -> libudev.so.1
libudev.so.1 -> libudev.so.1.0.1
libudev.so.1.0.1 -> libudev.so.1.5.1
libudev.so.1.5.1 -> libudev.so.1.5.2
libudev.so.1.5.2 -> libudev.so.1.6.0
libudev.so.1.6.0 -> libudev.so.1.6.4
libudev.so.1.6.4
will try if that works now
best regards
Scooby
On 2015-09-05 22:57, shraptor wrote:
When I read jude's documentation it states
"It also ships with a "libudev-compat" library that is ABI-compatible
with libudev 219."
My system is libudev 224, does this mean it isn't ABI-compatible
anymore?
if so how to handle?
On 2015-09-05 21:49, shraptor wrote:
I also forgot to say that on my upgraded system with vdev and
arch version of xf86-input-evdev touchpad gets detected and loaded
that I believe is
fascilitated by evdev and libudev-compat??
best regards
Scooby
On 2015-09-05 21:40, shraptor wrote:
Just to be clear my system before upgrade was using vdev in
conjunction with
xf86-input-evdev and working fine. I did not recompile that version
of
evdev and it
just worked with libudev-compat.
When I upgraded to new version of both( and new kernel)
keyboard stopped working( though could be brought to life with static
conf in xorg.conf.d).
I thought maybe arch had done something to break functionality
here. It could also be some regression in vdev and I will speak
to jude about that after September 12 when he's got more time.
@Jack Frost
I do not understand the use of .pc files although I have seen them
around. I am using your systemd-dummy package though to avoid pulling
in real systemd, Thanks for that.
Isaac I know about your package and have checked it out before
but didn't fully understand it.
What is triggering evdev in your case? a file in xorg.conf.d?
I am gonna try your solution with libsysdev and sysdev branch
of xf86-input-evdev. Although it would easier( for me that is) if
the arch version just worked with vdev.
I love that you give full explanation, thanks
best regards
Scooby
On 2015-09-05 20:36, Isaac Dunham wrote:
On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote:
On arch linux xf86-input-evdev is reported to have a dependency on
systemd.
I thought the dependency is on udev and that is usually reported on
arch
like
systemd(udev).
I downloaded xf86-input-evdev for recompilation but could not find
any
switches
to compile without systemd though some evidence pointing at a udev
dependency was there.
Does anyone know?
Long explanation here.
xf86-input-evdev, as shipped by upstream, is intended to be loaded
by Xorg's
hotplug support, which depends on libudev (or an API-compatible
replacement
such as libudev-compat or libeudev...); at least in theory, you can
also
use it as a pre-configured device driver.
The hotplug path will load evdev for *all* input devices that are
hotplugged--power buttons included.
So, evdev needs to check if a device is "virtual".
This is a simple matter of checking that the canonical path in sysfs
contains the string "LNXSYSTM".
Getting that canonical path is the hard part, since you receive a
device
path instead of anything pointing into sysfs.
This can be done more-or-less by getting the device major and minor
via stat(), checking that it's a char device, then identifying the
corresponding link in /sys/dev/ - this would be the string returned
by:
sprintf(buf, "/sys/dev/char/%hu:%hu", major, minor)
and then use readlink() to check where it points; the result is the
canonical path.
However, most people prefer to avoid depending on the sysfs layout
even
where its behavior is documented; libudev provides a thin veneer to
hide
it.
So in src/evdev.c, function EvdevDeviceIsVirtual, they use libudev
to do
this.
There is no dependency on udev being running.
I've redone that function without udev but using my own library
libsysdev,
which I mentioned earlier this summer.
Repositories that you'd need to build that:
-https://github.com/idunham/libsysdev
-https://github.com/idunham/xf86-input-evdev (branch sysdev)
But that does require something that has no Debian packaging yet.
There are also two other options:
- comment out that function and disable device hotplug in Xorg.conf
or
xorg.conf.d
- replace the function with one that does all the work itself.
HTH,
Isaac Dunham
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng1
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
