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@???
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>> _______________________________________________
>> Dng mailing list
>> Dng@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng1