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